Thoughts about the future of Unified CI

[galargh]

Unified CI 2.0 - the vision doc

TLDR

web3-bot becomes dependabot for Unified CI workflow distribution and continuous updates. It is easier to enroll new repositories. It is possible to customise Unified CI workflows directly in the workflow definition YML because web3-bot understands the file structure. web3-bot is helpful and can suggest updating not only reusable workflow versions, but also inputs or triggers.web3-bot respects repository owners wishes and their past choices.

Releases

Versioning

Unified CI repository is properly versioned using the semver scheme. Versions use vX.Y.Z format. The current version is stored in the CHANGELOG.md file.

Branching

There is a release branch for each version in the format of release/vX.Y.Z.

New release branches that follow the chronological order are created from the master branch.

The master branch is the default branch for the repository and this is where all the development happens.

Out of order release branches are created from the previous release branch.

Tagging

Tags are created for each release branch.

Releases that follow the chronological order are tagged with vX.Y.Z, vX.Y and vX tags.

Out of order releases are tagged with vX.Y.Z and vX.Y tags if they break the order of minor versions, and with vX.Y.Z, vX.Y and vX if they break the order of major versions.

Example Timeline

Time	Release	Branch	Source	Tags
1	v1.0.0	release/v1.0.0	master	v1.0.0, v1.0, v1
2	v1.1.0	release/v1.1.0	master	v1.1.0, v1.1, v1
3	v1.1.1	release/v1.1.1	master	v1.1.1, v1.1, v1
4	v1.2.0	release/v1.2.0	master	v1.2.0, v1.2, v1
5	v1.1.2	release/v1.1.2	release/v1.1.1	v1.1.2, v1.1
6	v1.1.3	release/v1.1.3	release/v1.1.2	v1.1.3, v1.1
7	v1.3.0	release/v1.3.0	master	v1.3.0, v1.3, v1
8	v2.0.0	release/v2.0.0	master	v2.0.0, v2.0, v2
9	v1.4.0	release/v1.4.0	release/v1.3.0	v1.4.0, v1.4, v1

Entities

Unified CI is a source of reusable workflows, actions and workflow templates.

Workflow Templates

Workflow Templates defined in the Unified CI repository are allowed to only reference Reusable Workflows. They cannot define any steps themselves.

References to Reusable Workflows should use proper version tags.

Reusable Workflows

Reusable Workflows defined in the Unified CI repository are the core of what makes Unified CI Unified CI. They define the logic we think should be executed in each PL repository.

References to Actions should use either proper version tags or commit SHAs.

Whenever possible, reusable workflows should use optional inputs.

Actions

Actions defined in the Unified CI repository help deduplicate common patterns seen across multiple Reusable Workflows. They can also serve as helper actions which could help repository owners enrich their Unified CI experience.

Whenever possible, actions should use optional inputs.

Enrollment

To enroll a repository in Unified CI all one has to do is to ensure web3-bot has write access to the repository.

Similarly, to opt-out of Unified CI, it is enough to revoke access to web3-bot.

Delivery

New Workflows

If a workflow is not defined in a target repository yet, web3-bot should suggest adding it to the reposiotry by creating it from Unified CI Workflow Template. If the suggestion is rejected by the repository owner, web3-bot should remember it and not suggest adding such workflow again.

Existing Workflows

If a workflow is already defined in the target repository, web3-bot should only suggest modifying the workflow. The allowed modifications are:

• reusable workflow version upgrades
• triggering events
• reusable workflow inputs

Not all modifications will be applicable for all releases - web3-bot should be smart enough to know when a modification suggestion is not needed. All rejected modifications should be remembered.

Retiring Workflows

If a workflow is not needed anymore, web3-bot should suggest removing a workflow from the target repository. It should do it at most once.

Language Upgrades

web3-bot should perform language version upgrades separately from workflow upgrades. If a workflow cannot be made version agnostic, it should accept version as input. Then, language upgrades from web3-bot will also upgrade the version passed on reusable workflow input.

Automerge

web3-bot should continue automerging PRs made by itself unless specifically told not to. It should be web3-bot who performs the merge operation.

Other

• web3-bot should respect the version precision the reusable workflows are requested with
• web3-bot could be silencable
• web3-bot could be a GitHub App for increased rate limits
• web3-bot could support a configuration file per repository
• web3-bot should be inspired by dependabot
• web3-bot should spread its operations in time (rate limits, less workflow runs started at the same time)
• web3-bot should use information about repository language to figure out what to propose for a repository

Why?

• Using proper versioning will reduce the workflow patch delivery time.
• Configuration through reusable workflow inputs and ability to modify the distributed workflows will make the process of customising Unified CI easier to understand for anyone with some experience with GitHub Actions.
• Easier customisation will allow us to reach more repositories/developers.
• I believe these changes will allow us to offer better DX for target repository maintainers, as well as Unified CI maintainers.

[BigLep]

Thanks for writing this up @galargh . What would be your primary before/after metrics you would look at to gauge the impact of this endeavor?

[galargh]

1. Decrease time spent on Unified CI maintenance by IPDX. I'd like to eliminate/minimise the need for our involvement in deploying Unified CI to new repositories and deploying new Unified CI releases. Right now, we reverted to semi-manual handling of both because they became too disruptive at the scale that Unified CI reached.
2. Increase the variety of workflows offered as part of Unified CI. I want it to be easier to introduce new workflows to Unified CI and to opt-in to a subset of optional workflows on the target repository side. With that, I'd like Unified CI to cover a wider range of automation needs. For example, I'd like us to be able to easily cover a variety of release workflows that are used/needed across PL, see docs: add H2 2023 roadmap pl-strflt/ipdx#82 (comment).
3. Increase development speed in Unified CI. This is kind of a combination of 1. and 2. With less time spent on maintenance and a push for more workflows inside Unified CI, I see development speed in this repository increasing. By this, I mean more undisruptive (only reaching those who are waiting for more frequent releases while not bothering the majority of the repos) Unified CI releases that focus on "features" (new workflows, speedups, UX improvements, etc.).

[galargh]

https://github.com/pl-strflt/uci is out! I'm going through the issues now, transferring what's relevant, and I'll archive this repo soon.