CI (Buildkite, GHA): Allow any user with triage or commit permissions…

… to retry all failed Buildkite jobs (#42138) (cherry picked from commit 5047920)
JuliaLang · Sep 15, 2021 · 32f8053 · 32f8053
1 parent f172ee5
commit 32f8053
Show file tree

Hide file tree

Showing 3 changed files with 63 additions and 9 deletions.
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -2,4 +2,5 @@ CODEOWNERS @JuliaLang/github-actions
 /.github/ @JuliaLang/github-actions
 /.buildkite/ @JuliaLang/github-actions
 
+/.github/workflows/retry.yml @DilumAluthge
 /.github/workflows/statuses.yml @DilumAluthge
diff --git a/.github/workflows/retry.yml b/.github/workflows/retry.yml
@@ -0,0 +1,59 @@
+# Please ping @DilumAluthge when making any changes to this file.
+
+# Here are some steps that we take in this workflow file for security reasons:
+# 1. We do not checkout any code.
+# 2. We only run actions that are defined in a repository in the `JuliaLang` GitHub organization.
+# 3. We do not give the `GITHUB_TOKEN` any permissions.
+# 4. We only give the Buildkite API token (`BUILDKITE_API_TOKEN_RETRY`) the minimum necessary
+#    set of permissions.
+
+# Important note to Buildkite maintainers:
+# In order to make this work, you need to tell Buildkite that it should NOT create a brand-new
+# build when someone closes and reopens a pull request. To do so:
+# 1. Go to the relevant pipeline (e.g. https://buildkite.com/julialang/julia-master).
+# 2. Click on the "Pipeline Settings" button.
+# 3. In the left sidebar, under "Pipeline Settings", click on "GitHub".
+# 4. In the "GitHub Settings", under "Build Pull Requests", make sure that the "Skip pull
+#    request builds for existing commits" checkbox is checked. This is the setting that tells
+#    Buildkite that it should NOT create a brand-new build when someone closes and reopens a
+#    pull request.
+# 5. At the bottom of the page, click the "Save GitHub Settings" button.
+
+name: Retry Failed Buildkite Jobs
+
+on:
+  # When using the `pull_request_target` event, all PRs will get access to secret environment
+  # variables (such as the `BUILDKITE_API_TOKEN_RETRY` secret environment variable), even if
+  # the PR is from a fork. Therefore, for security reasons, we do not checkout any code in
+  # this workflow.
+  pull_request_target:
+
+    # TODO: delete the following line (once we have completely transitioned from Buildbot to Buildkite)
+    types: [ reopened, labeled ]
+
+    # TODO: uncomment the following line (once we have completely transitioned from Buildbot to Buildkite)
+    # types: [ reopened ]
+
+# We do not give the `GITHUB_TOKEN` any permissions.
+permissions:
+  statuses: none
+
+jobs:
+  retry:
+    name: retry
+    runs-on: ubuntu-latest
+
+    # TODO: delete the following line (once we have completely transitioned from Buildbot to Buildkite)
+    if: github.repository == 'JuliaLang/julia' && (github.event.label.name == 'Buildkite - retry failed jobs' || github.event.action == 'reopened')
+
+    # TODO: uncomment the following line (once we have completely transitioned from Buildbot to Buildkite)
+    # if: github.repository == 'JuliaLang/julia'
+
+    steps:
+      # For security reasons, we do not checkout any code in this workflow.
+      - uses: JuliaLang/retry-buildkite@24e8341f74e0d6760717235eac936db639d7e9eb
+        with:
+          buildkite_api_token: ${{ secrets.BUILDKITE_API_TOKEN_RETRY }}
+          buildkite_organization_slug: 'julialang'
+          buildkite_pipeline_slug: 'julia-master'
+          pr_number: ${{github.event.number}}
diff --git a/.github/workflows/statuses.yml b/.github/workflows/statuses.yml
@@ -3,14 +3,11 @@
 # This is just a short-term solution until we have migrated all of CI to Buildkite.
 #
 # 1. TODO: delete this file once we have migrated all of CI to Buildkite.
-#
-# 2. TODO: disable GitHub Actions on the `JuliaLang/julia` repository once we have migrated all
-# of CI to Buildkite.
 
 # Here are some steps that we take in this workflow file for security reasons:
 # 1. We do not checkout any code.
 # 2. We do not run any external actions.
-# 3. We only give `GITHUB_TOKEN` the minimum necessary set of permissions.
+# 3. We only give the `GITHUB_TOKEN` the minimum necessary set of permissions.
 
 name: Statuses
 
@@ -27,7 +24,7 @@ on:
       - 'master'
       - 'release-*'
 
-# These are the permissions for the `GITHUB_TOKEN` token.
+# These are the permissions for the `GITHUB_TOKEN`.
 # We should only give the token the minimum necessary set of permissions.
 permissions:
   statuses: write
@@ -37,15 +34,12 @@ jobs:
     name: statuses
     runs-on: ubuntu-latest
     if: github.repository == 'JuliaLang/julia'
-    strategy:
-      fail-fast: false
     steps:
+      # For security reasons, we do not checkout any code in this workflow.
       - run: echo "SHA=${{ github.event.pull_request.head.sha }}" >> $GITHUB_ENV
         if: github.event_name == 'pull_request_target'
-
       - run: echo "SHA=${{ github.sha }}" >> $GITHUB_ENV
         if: github.event_name != 'pull_request_target'
-
       - run: echo "The SHA is ${{ env.SHA }}"
 
       # As we incrementally migrate individual jobs from Buildbot to Buildkite, we should