Repository files navigation

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:

1. 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.
2. 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 throughconfiguration variables.

You can customise the runner type forgo-test throughUCI_GO_TEST_RUNNER_UBUNTU,UCI_GO_TEST_RUNNER_WINDOWS andUCI_GO_TEST_RUNNER_MACOS configuration variables. This option will be useful for repositories wanting to use more powerful,PL self-hosted GitHub Actions runners. Make sure the value of the variable is valid JSON.

UCI_*_RUNNER_* variables expect the values to be JSON formatted. For example, if you want theMacOS runner used inGo Test workflow to bemacos-12 specifically, you'd setUCI_GO_TEST_RUNNER_MACOS to"macos-12" (notice the" around the string); and if you want yourUbuntu runner to be a self hosted machine with labelsthis,is,my,self-hosted,runner, you'd setUCI_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 forgo-test are defined in.github/actions/go-test-setup/action.yml, and setup steps forgo-check are defined in.github/actions/go-check-setup/action.yml, in the following format:

runs:using:"composite"steps:    -name:Step 1shell:bashrun:echo "do some initial setup"    -name:Step 2shell:bashrun: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 throughgithub.token variable in thegithub context. Unfortunately, the actions do not have access to thesecrets context.

You can configure Unified CI for your repository by creating a.github/uci.yml configuration file.

Here is an example configuration file:

files:# Configure what Unified CI templates should be used for your repository; defaults to primary language default fileset  -.github/workflows/go-check.yml  -.github/workflows/go-test.yml  -.github/workflows/release.ymlforce:true# Configure whether Unified CI should overwrite existing workflows; defaults to falseversions:uci:v1# Configure what version of Unified CI reusables should be used; defaults to latestgo:1.21# Configure what version of Go should be used; defaults to oldstable

go-check contains an optional step that checks that runninggo 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 setgogenerate totrue in.github/workflows/go-check-config.json:

{"gogenerate":true}

Note that depending on the code generators used, it might be necessary toinstall 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 usingbuild 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 and/or race detection tests setskip32bit/skipRace totrue in.github/workflows/go-test-config.json:

{"skip32bit":true,"skipRace":true}

If your project cannot be built on one of the supported operating systems, you can disable it by settingskipOSes to a list of operating systems in.github/workflows/go-test-config.json:

{"skipOSes": ["windows","macos"]}

If you want to disable verbose logging or test shuffling, you can do so by settingverbose orshuffle tofalse in.github/workflows/go-test-config.json:

{"verbose":false,"shuffle":false}

If you want to disable cgo, you can do so by settingcgo tofalse in.github/workflows/go-test-config.json:

{"cgo":false}

You can modify the workflows distributed by Unified CI as you wish. Unified CI will only ever try to update the versions of reusables after the initial distribution. Similarly to how dependabot operates.

In particular, you might want to update the organization part of the reusable's path to your organization in case your organization doesn't allow using reusables from outside organization or you intend to run reusables on self-hosted runners. If you fork the Unified CI repository and give write access to your fork to @web3-bot, your fork is going to be kept up to date automatically. This ensures the validity of all future, automatic Unified CI updates.

Unified CI is distributed to all repositories @web3-bot has write access to.

If you want your project to participle, give@web3-bot write access to your repository. If the invitation needs acceptance, please create an issue or reach out to us at#ipdx.

Unified CI consists oftemplates which arerendered using the combination ofdefault configuration andrepository specific configuration and distributed toparticipating repositories onschedule byCopy workflow. Distributed changes are proposed as Pull Requests byCreate workflow and automatically merged byMerge workflow when allowed.

All workflowtemplates distributed by Unified CI referencereusables which live in Unified CI repository. By default,Copy workflow proposes updatesONLY to the versions ofreusables - the same waydependabot operates. This ensures users are free to modify the workflows after distribution as they wish.

Unified CI repository can be forked to accomodate repositories that don't allow usage of reusables from outside the organization or intend to run reusables on self-hosted runners. The forks to which @web3-bot has write access are kept up to date automatically bySync workflow. This ensures the validity of all future, automatic Unified CI updates.

{"version":"v0.4.2"}