ci: generate outputs for pinning helios on release branches #8092
Conversation
There was a problem hiding this comment.
The bits I know about make sense to me, will let @jclulow accept after looking at the incorporation code.
| "origin", | ||
| "master", | ||
| ]) | ||
| .args(["fetch", "--no-write-fetch-head", "origin", "HEAD"]) |
There was a problem hiding this comment.
What does this change do?
There was a problem hiding this comment.
The remote's HEAD always refers to the default branch, if we ever end up renaming the branch. This is just a bit of unrelated futureproofing.
There was a problem hiding this comment.
I feel like it fetches whatever HEAD points to on the origin remote, without updating the local FETCH_HEAD ref? I think HEAD, at least on GitHub, points at the tip of the default branch in the repository?
There was a problem hiding this comment.
Ah gotcha -- could you add a comment?
| jobs.push("helios-record", async move { | ||
| let projects_dir = helios_dir.join("projects"); | ||
| let mut projects = BTreeMap::new(); | ||
| let mut read_dir = fs::read_dir(&projects_dir).await?; |
There was a problem hiding this comment.
Could use projects_dir.read_dir_utf8 here -- it isn't async but ehh, I don't think it matters.
| "origin", | ||
| "master", | ||
| ]) | ||
| .args(["fetch", "--no-write-fetch-head", "origin", "HEAD"]) |
There was a problem hiding this comment.
I feel like it fetches whatever HEAD points to on the origin remote, without updating the local FETCH_HEAD ref? I think HEAD, at least on GitHub, points at the tip of the default branch in the repository?
dev-tools/releng/src/main.rs
Outdated
| @@ -477,6 +513,19 @@ async fn main() -> Result<()> { | |||
| }}; | |||
| } | |||
|
|
|||
| let incorp_version = version.major; | |||
There was a problem hiding this comment.
Wondering if we should make this MAJOR.0.0.0 just for symmetry with the rolls we've been doing for respins?
| #: "=/work/incorporation.p5m", | ||
| #: "=/work/incorporation.p5p", |
There was a problem hiding this comment.
@jclulow this won't throw an error if these files aren't present on release branches, right? Or do I need a different sigil here to make these "optional"?
edit: = means mandatory, so I should correct this either by removing the = or writing out a file anyway if we're pinned to one in the repo.
|
In addition to some changes suggested in review I've added an I still need to write up the code to pass through the incorporation from the repo so that Buildomat doesn't fail on release branches, and then I will automerge. |
This generates some new files that can be used to pin Helios more completely on release branches. We do not pin Helios on the main branch of Omicron by design, but we want to prevent unexpected changes in release branches.
The first file is
helios.json, which contains the commit hash for Helios as well as the (currently) eight repositories helios-setup fetches. Since v13 we've started branching the Helios repository as well and pinning the commits of the repos it pulls down. I've been downloading the repos and pulling the recorded commits out of the OS tarballs, but this new CI artefact will make writing a tool to do this more tractable.The other files are for the release incorporation package. Since v10 we've published a package to the Helios repository named
omicron-release-incorporation, which creates an incorporation dependency on the latest version of each package in the repository except for itself anddriver/network/opte(this version is controlled bytools/opte_version). From pkg(7) § Constraints and Freezing:Previously this was generated via Makefile and scripts found at
/staff/rel/*when the branch was to be made. Generation and use of a proposedomicron-release-incorporationat CI time means that a branched release can pin to precisely the same packages that were present in the base commit on the main branch (as well as ensuring that the host OS and recovery/trampoline OS contain packages with the same versions). This depends on oxidecomputer/helios#200, which allows for multiple origins to be set for a publisher.At branch time, the
incorporation.p5pcan be pkgrecv'd into the Helios repository, andtools/pins.tomlwill reflect that version; when this is set the releng tool will stop generating the incorporation and use the one present in the repository. If any package updates are required on the release branch,incorporation.p5mcan be used as a starting point.