You can find it at https://github.com/pl-strflt/uci
If you want to add Unified CI to your repository, give @web3-bot push access to your repository. That's it!
You can read more about it at https://github.com/pl-strflt/uci#usage
Welcome to Unified CI, your key to deploying and managing GitHub Actions workflows across an extensive network of repositories. Unified CI takes the helm in orchestrating both the initial deployment and ongoing updates of workflows, providing a seamless solution to streamline your projects' lifecycle.
With Unified CI at your side, Protocol Labs can effortlessly oversee GitHub Actions workflows throughout numerous organizations and hundreds of repositories. This automated system guarantees:
- Consistency: Through the utilization of identical GitHub Actions workflow definitions across participating repositories, Unified CI assures that code maintains the highest standard and undergoes thorough testing.
- Maintainability: Workflow definitions are constantly refreshed under Unified CI's management. Any changes in the definitions are instantly relayed to all participating repositories, guaranteeing up-to-date operations.
Unified CI is currently available for both Go and JavaScript (JS), providing a wide array of automated services for each:
-
Go: Unified CI's Go support includes testing with the current and previous versions of Go, and performing tests on Windows, macOS, and Linux. It ensures comprehensive testing, including on 32-bit infrastructure, and for race conditions. Besides testing, it also handles linting and formatting for Go code, providing a well-rounded CI solution. Moreover, the release process is also automated via GitHub Releases.
-
JavaScript: For JavaScript, Unified CI ensures testing across various platforms: Windows, Linux, and macOS. It also conducts tests in multiple environments, including Node, Chrome, Firefox, Webkit, WebWorkers, and Electron. Similar to Go, it also automates the release process, ensuring a streamlined workflow.
We understand the growing needs of different programming languages in the development community, and we're excited to share that we have plans to extend Unified CI support to Rust and Python. This will allow us to provide our robust CI solution to an even broader range of developers. Stay tuned for future updates on this expansion!
Most repositories won't need any customization, and the workflows defined here will just work fine.
Some aspects of Unified CI workflows are configurable through configuration variables.
You can customise the runner type for go-test through UCI_GO_TEST_RUNNER_UBUNTU, UCI_GO_TEST_RUNNER_WINDOWS and UCI_GO_TEST_RUNNER_MACOS configuration variables. This option will be useful for repositories wanting to use more powerful, PL self-hosted GitHub Actions runners.
UCI_*_RUNNER_* variables expect the values to be JSON formatted. For example, if you want the MacOS runner used in Go Test workflow to be macos-12 specifically, you'd set UCI_GO_TEST_RUNNER_MACOS to "macos-12" (notice the " around the string); and if you want your Ubuntu runner to be a self hosted machine with labels this, is, my, self-hosted, runner, you'd set UCI_GO_TEST_RUNNER_UBUNTU to ["this", "is", "my", "self-hosted", "runner"].
Some repositories may require some pre-setup steps to be run before tests (or code checks) can be run. Setup steps for go-test are defined in .github/actions/go-test-setup/action.yml, and setup steps for go-check are defined in .github/actions/go-check-setup/action.yml, in the following format:
runs:
using: "composite"
steps:
- name: Step 1
shell: bash
run: echo "do some initial setup"
- name: Step 2
shell: bash
run: echo "do some Linux-specific setup"
if: ${{ matrix.os == 'ubuntu' }}These setup steps are run after the repository has been checked out and after Go has been installed, but before any tests or checks are run.
If you need to access the GitHub Token in a setup action, you can do so through github.token variable in the github context. Unfortunately, the actions do not have access to the secrets context.
go-check contains an optional step that checks that running go generate doesn't change any files.
This is useful to make sure that the generated code stays in sync.
This check will be run in repositories that set gogenerate to true in .github/workflows/go-check-config.json:
{
"gogenerate": true
}Note that depending on the code generators used, it might be necessary to install those first. The generators must also be deterministic, to prevent CI from getting different results each time.
go-test offers an option to completely disable running 32-bit tests.
This option is useful when a project or its upstream dependencies are not 32-bit compatible.
Typically, such tests can be disabled using build constraints.
However, the constraints must be set per go file, which can be cumbersome for a project with many files.
Using this option, 32-bit tests can be skipped entirely without having to specify build constraints per file.
To completely disable running 32-bit tests set skip32bit to true in .github/workflows/go-test-config.json:
{
"skip32bit": true
}If your project cannot be built on one of the supported operating systems, you can disable it by setting skipOSes to a list of operating systems in .github/workflows/go-test-config.json:
{
"skipOSes": ["windows", "macos"]
}You can opt-in to receive early updates from the next branch in-between official Unified CI releases.
To do so you have to set source_ref property to next on your repository target object in the configuration file.
{
"repositories": [
{
"target": "pl-strflt/example",
"source_ref": "next"
}
]
}Warning: next branch updates are much more frequent than those from master.
This repository currently defines two workflows for Go repositories:
- go-check: Performs static analysis, style, and formatting checks to help improve the code quality.
- go-test: Runs all tests, using different compiler versions and operating systems.
Whenever one of these workflows is changed, this repository runs the copy workflow. This workflow creates a pull request in every participating repository to update go-check and go-test. In order to help with the distribution of these workflows, this repository defines two additional workflows that are distributed across participating repositories:
- automerge: In most cases, an update to the workflows will not cause CI to fail in most participating repositories. To make our life easier, automerge automatically merges the pull request if all checks succeed.
Workflows are distributed to all repositories listed in configs/go.json.
If you want your project to participle, please send a PR which adds your repository to the config! Remember to ensure @web3-bot has write access to your repository.
The master branch contains currently deployed workflows.
When we make minor changes to these workflows, we don't always want these changes to get deployed to all hundreds of repositories, as this creates a lot of unnecessary noise. Minor changes to the workflows are therefore merged into the next branch. When the time has come, we create a PR from the next branch to master to trigger a deployment to all repositores.
If you're using Visual Studio Code for development, you might want to install the YAML extension. It is configured to perform GitHub workflow/action linting out-of-the-box. If you're using a different IDE, you can check if a client for it exists.