Skip to content

Latest commit

 

History

History
225 lines (171 loc) · 7.72 KB

18_migrate_ci_to_gh_actions.md

File metadata and controls

225 lines (171 loc) · 7.72 KB

enhancement-18: Migrate CI to Github Actions

Release Signoff Checklist

  • 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]

Summary

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.

Motivation

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

Goals

  • Provide the same test coverage as Travis curently offers using Github Actions.
  • Once the above is complete: Stop using Travis on Keylime repos completely.

Non-Goals

Proposal

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).

User Stories (optional)

Story 1

Story 2

Notes/Constraints/Caveats (optional)

Risks and Mitigations

TBD

Design Details

TBD

Test Plan

TBD

Upgrade / Downgrade Strategy

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.

Drawbacks

Some extra implementation work, though for a good payoff.

Alternatives

Infrastructure Needed (optional)

Likely some cooperation from project admins at times.