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
