When we manually run the daily-snapshot job to make a specific commit,
the resulting release should be named based on the release commit, not
the trigger commit.
When we build a release, it is always a "past" commit - typically, one
that has already been tested twice: once when the corresponding PR was
run, and then again as a "main"-branch commit.
Release branches don't run, but their protection rules enforce linear
merges.
Either way, we know we're building a _good_ commit, and, assuming our
builds and tests are hermetic, testing that commit again when we make a
release is a pure waste of time and CPU resources.
The other case, where we make an ad-hoc release from a branch that has
not been merged, has a similar issue: we do not necessarily want to run
the full test suite, because part of the reason we need that commit may
be that it doesn't succeed as is.
Based on that observation, I wondered what might be the minimal set of
things we actually need to build when making a release. This PR is an
experiment in trying to find that out.
When we build a release, it is always a "past" commit - typically, one
that has already been tested twice: once when the corresponding PR was
run, and then again as a "main"-branch commit.
Release branches don't run, but their protection rules enforce linear
merges.
Either way, we know we're building a _good_ commit, and, assuming our
builds and tests are hermetic, testing that commit again when we make a
release is a pure waste of time and CPU resources.
The other case, where we make an ad-hoc release from a branch that has
not been merged, has a similar issue: we do not necessarily want to run
the full test suite, because part of the reason we need that commit may
be that it doesn't succeed as is.
Based on that observation, I wondered what might be the minimal set of
things we actually need to build when making a release. This PR is an
experiment in trying to find that out.
This PR moves the whole "update canton" logic to a script anyone can run
locally, and changes it to be able to get any canton commit we want, or
possibly any dirty local workdir.
Right now building Linux/ARM fails on release branches. This is because:
- Release branches do not support Linux/ARM.
- Releases are built from `main`, using `main`'s version of YAML files.
This should skip over the Linux/ARM build when running on release
branches.
This job runs on both `main` and `main-2.x`, and generates the same
branch name. This results in only the first of the two that runs
generating a PR.
With this change the branch name will be different so when an update is
needed we'll update both on the same day.
