- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
CI (Buildkite, GHA): Allow any user with triage or commit permissions to retry all failed Buildkite jobs #42138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
fb5655e
5c5a1d7
8803ce3
13c6a2b
b7d8472
d0c24e5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this still relevant? I thought this PR was buildkite-specific and has nothing to do with buildbot. |
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same note as above; can't someone malicious just edit the yml? |
||
- 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}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these TODOs still relevant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This deserves some explanation.
Okay, so if you look at the workflow file currently, you'll see it runs on two types of event:
Buildkite - retry failed jobs
label is added to a PR.Once we have fully migrated to Buildkite, I will remove option 1 and only have option 2.
In the current situation, in which we have both Buildbot and Buildkite, here is what happens in each event:
Once we have migrated everything to Buildkite, and we no longer have anything on Buildbot, here is what happens in each event:
So, currently (in the Buildbot + Buildkite world), the "Label is added" event is preferable, because it doesn't rerun the passed Buildbot jobs, and thus conserves CI resources.
But in the future Buildkite-only world, the "Label is added" event is exactly identical in effect to the "PR is reopened after being closed" event. And I think, personally, that telling someone to "close and reopen a PR, and it will only rerun failed CI" is a much more user-friendly interface than this label business.
So, once we are in the Buildkite-only world, I want to completely remove the label trigger, and only have the "close and reopen the PR" trigger, because I think it's easier for people to use.
So these TODOs are here to remind me to get rid of the label stuff once we are Buildkite-only.
What do you think?