tweak release process for more reliable labeling (digital-asset#5823)

Currently, there are quite a few releases that are lacking the Standard-Change label, even though they did publish artifacts. This makes our SOC2-compliance tracking a bit harder. For the past two months, I have manually added the label after-the-fact while preparing the monthly compliance report, but that doesn't seem like a great solution. This PR changes the release process to be more optimistic: assume the release is going to succeed by putting in the label immediately, and then (optionally) removing it if the release fails. Note that the label should only be removed in the rare case where the release was merged into master but somehow did not produce any artifact. This can only happen if the Linux build fails quite early, which as far as I know only happened once over the past two months when we had the release notes race condition. CHANGELOG_BEGIN CHANGELOG_END
axman6 · May 4, 2020 · 49b4a8d · 49b4a8d
1 parent 0a7575d
commit 49b4a8d
Show file tree

Hide file tree

Showing 2 changed files with 11 additions and 5 deletions.
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
@@ -53,15 +53,15 @@ jobs:
       - bash: |
           set -euo pipefail
 
-          has_changed_infra_folder () {
-              git diff $(fork_sha) $(branch_sha) --name-only | grep -q '^infra/'
+          has_changed () {
+              git diff $(fork_sha) $(branch_sha) --name-only | grep -q "^$1/"
           }
 
           fail_if_missing_std_change_label () {
               curl https://api.github.com/repos/digital-asset/daml/pulls/$PR -s | jq -r '.labels[].name' | grep -q '^Standard-Change$'
           }
 
-          if has_changed_infra_folder; then
+          if has_changed "infra" || has_changed "LATEST"; then
               fail_if_missing_std_change_label
           fi
         env:

diff --git a/release/RELEASE.md b/release/RELEASE.md
@@ -15,6 +15,9 @@ snapshot, so we "bless" an existing, tested version of the SDK rather than try
 our luck with a random new one. For a snapshot, this should generally be the
 latest commit on master.
 
+> **IMPORTANT**: If the release fails, please do not just abandon it. There are
+> some cleanup steps that need to be taken.
+
 1. **[STABLE]** Coordinate with the product and marketing teams to define
    release highlights, tweets, blog posts, as well as timeline for publishing
    the release. Define a version number, `$VERSION`. The following command may
@@ -70,8 +73,11 @@ latest commit on master.
       you will have to manually add wrap them in double backslashes.
 
 1. Once this is done, create a GitHub pull request (PR) with the above changes
-   to the `LATEST` and (for a stable release) `release-notes.rst` files.
-   It is important that your PR changes no other file.
+   to the `LATEST` and (for a stable release) `release-notes.rst` files. It is
+   important that your PR changes no other file. Your PR also needs to have the
+   `Standard-Change` label. Note that if the build failed because of this, you
+   should be able to add the label and "rerun failed checks" in a few seconds;
+   there is no need to restart an entire build cycle.
 
 1. Get a review and approval on your PR and then merge it into master.
    **[STABLE]** For a stable release, the approval **MUST** be from the team