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.
* do not run pr-only tests on main, do not run main-only tests on prs
* split data dep tests into main-only and pr-only
* run non-dev conformance tests on main only
This adds parameters to the "split release" job. At the moment, when
run, the job just builds the current commit with a snapshot version.
With this change, we'll be able to build a split release for any commit
with any version tag.
The reason for this change is we want to trigger this job from the
assembly repo, to reduce the number of manual interventions needed in
the release process.
CHANGELOG_BEGIN
CHANGELOG_END
The release process for 2.1.0 is ongoing. I think it's safe to say at
this point if we need to change the RC we'll do it with backports.
CHANGELOG_BEGIN
CHANGELOG_END
In some cases we may end up with the tip of the main branch built as a
split release manually. When Azure then tries to run it, the release
fails (typically on the upload to NPM step).
Normally, Azure is set to run this only once per commit, but that only
applies when the run is successful. So if it breaks in a reproducible
way (e.g. because the version already exists on NPM), Azure will keep
trying every day.
This PR adds a simple guard that makes the nightly build _not_ a release
commit if the reelease already exists, which should short-circuit most
of the jobs in the build and finish successfully.
CHANGELOG_BEGIN
CHANGELOG_END
Because there's no reason not to. The only obstacle to automating the
normal release process is that we need an explicit manual validation
step for our audit log when creating a release, but split-releases are
created in the Assemblty repo, so we can have the audit log over there.
The diff is going to be very messy because there's a lot of stuff moving
around. The only thing that is not just moving a job to a separate file
is the `ci/daily-snapshot.yml` file, which is 100% new and is meant as
a new Azure Pipelines entrypoint (which I will create after this gets
approved). I have made a reasonable effort to create individual commits
that simplify reviewing, but I expect it's still going to be kind of a
mess. I'm open to opening separate PRs to ~bump my stats~ move one job
at a time if that makes reviewing (and testing) easier.
CHANGELOG_BEGIN
CHANGELOG_END
