- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
- Core members have approved the issue with the label
implementable
- Design details are appropriately documented
- Test plan is in place
- User-facing documentation has been created in [keylime/keylime-docs]
The Keylime project's current CI pipeline is implemented using Travis CI's toolset. While functional, the team has noticed some shortcomings around reliability, performance, and general integration with Github.
In the meantime, Github has rolled out its homegrown Github Actions CI and test system to general availability. Project contributors that have used the system for other projects have noted its general improvements over Travis, and the project would like to transition its existing CI setup over to Actions.
Keylime's current CI pipeline isn't satisfactory to the project's contributors, and better alternatives (notably Github Actions) exists. We would like to switch to Actions entirely.
In particular, Github Actions is:
- Directly integrated into Github's UI
- Fast -- jobs start quickly, and most lead time happens at compilation or environment setup
- Extensible -- there are thousands of actions available for a wide variety of tasks
- Familar -- fits the fork-request-merge model just like developers expect modern CI to behave
- Provide the same test coverage as Travis curently offers using Github Actions.
- Once the above is complete: Stop using Travis on Keylime repos completely.
Keylime's current Travis config is located, as all Travis configs are, in
~/.travis.yml
. All fundamental functionality of this config should be
replicated in an equivalent Actions workflow, which would be housed under, for
example, ~/.github/workflows/test.yml
.
The current config makes use of several containers. It will be worth investigating whether these containers can be run on Github's standard runners, and how we might have to change the containers to fully migrate (if at all).
TBD
TBD
TBD
As Actions is an entirely separate system from Travis, it's feasible to build out an Actions presence while still using Travis. When we believe Actions works sufficiently, we can simply turn Travis off.
Github Actions configs can be updated by simply changing their workflow file in a pull request.
Changes to existing workflows via PR will be reflected in the workflow that runs on the PR that makes the changes. This is particularly handy for code tests.
Some extra implementation work, though for a good payoff.
Likely some cooperation from project admins at times.