GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — tools: make env variables consistent in cron jobs · nodejs/node@41edd2f

File tree

Expand file treeCollapse file tree

Open diff view settings

Filter options

.github/workflows
- auto-start-ci.yml
- commit-queue.yml
doc/contributing
- commit-queue.md
tools/actions
- commit-queue.sh
- start-ci.sh

Expand file treeCollapse file tree

Open diff view settings

Collapse file

`‎.github/workflows/auto-start-ci.yml‎`

Copy file name to clipboardExpand all lines: .github/workflows/auto-start-ci.yml

+9-5Lines changed: 9 additions & 5 deletions

Original file line number	Diff line number	Diff line change
`@@ -1,3 +1,6 @@`
	`1`	`+# This action uses the following secrets:`
	`2`	`+# JENKINS_USER: GitHub user whose Jenkins token is defined below`
	`3`	`+# JENKINS_TOKEN: Jenkins token, to be used to start CI`
`1`	`4`	`name: Auto Start CI`
`2`	`5`
`3`	`6`	`on:`
`@@ -36,11 +39,13 @@ jobs:`
`36`	`39`	`-t '{{ range . }}{{ .number }} {{ end }}' \`
`37`	`40`	`--limit 5)" >> "$GITHUB_OUTPUT"`
`38`	`41`	`env:`
`39`		`- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}`
	`42`	`+ GH_TOKEN: ${{ github.token }}`
`40`	`43`	`start-ci:`
`41`	`44`	`permissions:`
	`45`	`+ checks: read`
`42`	`46`	`contents: read`
`43`	`47`	`pull-requests: write`
	`48`	`+ statuses: read`
`44`	`49`	`needs: get-prs-for-ci`
`45`	`50`	`if: needs.get-prs-for-ci.outputs.numbers != ''`
`46`	`51`	`runs-on: ubuntu-slim`
`@@ -59,16 +64,15 @@ jobs:`
`59`	`64`	`ncu-config set token "$GH_TOKEN"`
`60`	`65`	`ncu-config set jenkins_token "$JENKINS_TOKEN"`
`61`	`66`	`ncu-config set owner "$GITHUB_REPOSITORY_OWNER"`
`62`		`- ncu-config set repo "$(echo "$GITHUB_REPOSITORY" \| cut -d/ -f2)"`
	`67`	`+ ncu-config set repo "${GITHUB_REPOSITORY#*/}"`
`63`	`68`	`env:`
`64`	`69`	`USERNAME: ${{ secrets.JENKINS_USER }}`
`65`		`- GH_TOKEN: ${{ secrets.GH_USER_TOKEN }}`
	`70`	`+ GH_TOKEN: ${{ github.token }}`
`66`	`71`	`JENKINS_TOKEN: ${{ secrets.JENKINS_TOKEN }}`
`67`	`72`
`68`	`73`	`- name: Start the CI`
`69`	`74`	`run: \|`
`70`	`75`	`curl -fsSL "https://github.com/${GITHUB_REPOSITORY}/raw/${GITHUB_SHA}/tools/actions/start-ci.sh" \`
`71`	`76`	`\| sh -s -- ${{ needs.get-prs-for-ci.outputs.numbers }}`
`72`	`77`	`env:`
`73`		`- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}`
`74`		`- GH_REPO: ${{ github.repository }}`
	`78`	`+ GH_TOKEN: ${{ github.token }}`

Collapse file

`‎.github/workflows/commit-queue.yml‎`

Copy file name to clipboardExpand all lines: .github/workflows/commit-queue.yml

+6-10Lines changed: 6 additions & 10 deletions

Original file line number	Diff line number	Diff line change
`@@ -52,7 +52,7 @@ jobs:`
`52`	`52`	`jq -r -s 'reduce .[] as $pr ([]; if index($pr) then . else . + [$pr] end) \| join(" ")')`
`53`	`53`	`echo "candidates=$candidates" >> "$GITHUB_OUTPUT"`
`54`	`54`	`env:`
`55`		`- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}`
	`55`	`+ GH_TOKEN: ${{ github.token }}`
`56`	`56`	`commitQueue:`
`57`	`57`	`needs: get_candidate_prs`
`58`	`58`	`if: needs.get_candidate_prs.outputs.candidates != ''`
`@@ -63,18 +63,14 @@ jobs:`
`63`	`63`	`statuses: read`
`64`	`64`	`runs-on: ubuntu-slim`
`65`	`65`	`steps:`
`66`		`- # Install dependencies`
`67`	`66`	`- name: Install Node.js`
`68`	`67`	`uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0`
`69`	`68`	`with:`
`70`	`69`	`node-version: ${{ env.NODE_VERSION }}`
	`70`	`+`
`71`	`71`	`- name: Install @node-core/utils`
`72`	`72`	`run: npm install -g @node-core/utils`
`73`	`73`
`74`		`- - name: Set variables`
`75`		`- run: \|`
`76`		`- echo "REPOSITORY=$(echo "$GITHUB_REPOSITORY" \| cut -d/ -f2)" >> "$GITHUB_ENV"`
`77`		`-`
`78`	`74`	`- name: Configure @node-core/utils`
`79`	`75`	`run: \|`
`80`	`76`	`# Keep the config outside the workspace so checkout does not remove it.`
`@@ -83,7 +79,7 @@ jobs:`
`83`	`79`	`ncu-config --global set username "$USERNAME"`
`84`	`80`	`ncu-config --global set token "$GH_TOKEN"`
`85`	`81`	`ncu-config --global set jenkins_token "$JENKINS_TOKEN"`
`86`		`- ncu-config --global set repo "${REPOSITORY}"`
	`82`	`+ ncu-config --global set repo "${GITHUB_REPOSITORY#*/}"`
`87`	`83`	`ncu-config --global set owner "${GITHUB_REPOSITORY_OWNER}"`
`88`	`84`	`env:`
`89`	`85`	`USERNAME: ${{ secrets.JENKINS_USER }}`
`@@ -102,8 +98,6 @@ jobs:`
`102`	`98`	`metadata="${RUNNER_TEMP}/metadata-${pr}.json"`
`103`	`99`	`output="${RUNNER_TEMP}/metadata-${pr}.txt"`
`104`	`100`	`if git node metadata "$pr" \`
`105`		`- --owner "$GITHUB_REPOSITORY_OWNER" \`
`106`		`- --repo "$REPOSITORY" \`
`107`	`101`	`--readme "$readme" \`
`108`	`102`	`--json > "$metadata" 2> "$output"; then`
`109`	`103`	`metadata_status=0`
`@@ -171,7 +165,9 @@ jobs:`
`171`	`165`	`- name: Start the Commit Queue`
`172`	`166`	`if: steps.get_mergeable_prs.outputs.numbers != ''`
`173`	`167`	`run: \|`
	`168`	`+ git config --local user.email "[email protected]"`
	`169`	`+ git config --local user.name "Node.js GitHub Bot"`
`174`	`170`	`ncu-config set token "$GH_TOKEN"`
`175`		`- ./tools/actions/commit-queue.sh "${GITHUB_REPOSITORY_OWNER}" "${REPOSITORY}" ${{ steps.get_mergeable_prs.outputs.numbers }}`
	`171`	`+ ./tools/actions/commit-queue.sh ${{ steps.get_mergeable_prs.outputs.numbers }}`
`176`	`172`	`env:`
`177`	`173`	`GH_TOKEN: ${{ secrets.GH_USER_TOKEN }}`

Collapse file

`‎doc/contributing/commit-queue.md‎`

Copy file name to clipboardExpand all lines: doc/contributing/commit-queue.md

+8-158Lines changed: 8 additions & 158 deletions

Display the source diff
Display the rich diff

Original file line number	Diff line number	Diff line change
`@@ -11,174 +11,24 @@ blocked on a deferrable condition, currently wait time, the queue leaves the`
`11`	`11`	`label in place and retries later. Other failures continue to the existing`
`12`	`12`	`landing and failure-reporting path.`
`13`	`13`
`14`		`-This document gives an overview of how the Commit Queue works, as well as`
`15`		`-implementation details, reasoning for design choices, and current limitations.`
`16`		`-`
`17`		`-## Overview`
`18`		`-`
`19`		`-From a high-level, the Commit Queue works as follows:`
`20`		`-`
`21`		-1. Collaborators will add `commit-queue` label to pull requests they want the
`22`		`- queue to land. The label can be added before the pull request has completed`
`23`		`- its wait time. Required approvals must already be in place, and any required`
`24`		`- CI must have completed successfully. The commit queue does not request CI on`
`25`		`- its own.`
`26`		`-2. On each scheduled run, the queue builds a candidate list from open pull`
`27`		- requests with the `commit-queue` label and without the `blocked` label. A
`28`		`- candidate must also either have been created at least two days earlier or`
`29`		- have the `fast-track` label. Other labeled pull requests retain the label
`30`		`- until they become old enough or are fast-tracked. The workflow uses a`
`31`		`- five-minute cron, but GitHub Actions scheduled workflows are not guaranteed`
`32`		`- to run exactly every five minutes. For each candidate, the queue will:`
`33`		- 1. In the landing job, install and configure `@node-core/utils`, then run a
`34`		`- metadata-only readiness check without checking out the repository`
`35`		`- 2. If the metadata check exits with a deferrable readiness code, meaning`
`36`		- the PR is only blocked on wait time, keep the `commit-queue` label and
`37`		`- skip this PR until a later queue run`
`38`		- 3. Run `git node land` for ready PRs and PRs with hard or mixed readiness
`39`		- failures, keeping the `commit-queue` label in place during the attempt
`40`		`- 4. If it fails:`
`41`		- 1. Replace the `commit-queue` label with the `commit-queue-failed` label
`42`		- 2. Leave a comment on the PR with the output from `git node land`
`43`		- 3. Abort the `git node land` session. If the abort succeeds, continue to
`44`		`- the next PR; otherwise, stop the queue in an unknown state`
`45`		`- 5. If it succeeds:`
`46`		`- 1. Push or merge the changes into nodejs/node`
`47`		- 2. Leave a comment on the PR with `Landed in ...`
`48`		`- 3. Close the PR`
`49`		- 4. Remove the `commit-queue` label
`50`		`- 5. Go to next PR in the queue`
`51`		`-`
`52`	`14`	`To make the Commit Queue squash all the commits of a pull request into the`
`53`	`15`	first one, add the `commit-queue-squash` label.
`54`	`16`	`To make the Commit Queue land a pull request containing several commits, add the`
`55`	`17`	`commit-queue-rebase` label. When using this option, make sure
`56`	`18`	`that all commits are self-contained, meaning every commit should pass all tests.`
`57`	`19`
	`20`	+The implementation is in `commit-queue.yml` and `commit-queue.sh`.
	`21`	`+`
`58`	`22`	`## Current limitations`
`59`	`23`
`60`		`-The Commit Queue feature is still in early stages, and as such it might not`
`61`		`-work for more complex pull requests. These are the currently known limitations`
`62`		`-of the commit queue:`
	`24`	`+These are the currently known limitations of the commit queue:`
`63`	`25`
`64`	`26`	`1. All commits in a pull request must either be following commit message`
`65`	`27`	guidelines or be a valid [`fixup!`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt)
`66`	`28`	commit that will be correctly handled by the [`--autosquash`](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash)
`67`		`- option`
`68`		`-2. A CI must have run and succeeded since the last change on the PR`
`69`		`-3. A collaborator must have approved the PR since the last change`
`70`		`-4. Only Jenkins CI and GitHub Actions are checked (V8 CI and CITGM are ignored)`
	`29`	`+ option.`
	`30`	`+2. A CI must have run and succeeded since the last change on the PR.`
	`31`	`+3. A collaborator must have approved the PR since the last change.`
	`32`	`+4. Only Jenkins CI and GitHub Actions are checked (V8 CI and CITGM are ignored).`
`71`	`33`	5. The PR must target the `main` branch (PRs opened against other branches, such
`72`		`- as backport PRs, are ignored)`
`73`		`-`
`74`		`-## Implementation`
`75`		`-`
`76`		`-The [action](../../.github/workflows/commit-queue.yml) runs on scheduled events.`
`77`		`-It uses a five-minute cron because that is the smallest interval accepted by`
`78`		`-GitHub Actions. Scheduled workflows are not guaranteed to run exactly at that`
`79`		`-cadence and might take longer between runs.`
`80`		`-`
`81`		`-The workflow also uses a concurrency group so only one commit queue run can be`
`82`		`-active at a time. If a scheduled run starts while a previous run is still`
`83`		`-running, GitHub Actions keeps at most one pending run for the same concurrency`
`84`		`-group. A newer pending run replaces an older pending run.`
`85`		`-`
`86`		`-Using the scheduler is preferable over using pull\_request\_target for two`
`87`		`-reasons:`
`88`		`-`
`89`		`-1. if two Commit Queue Actions execution overlap, there's a high-risk that`
`90`		`- the last one to finish will fail because the local branch will be out of`
`91`		- sync with the remote after the first Action pushes. `issue_comment` event
`92`		`- has the same limitation.`
`93`		-2. `pull_request_target` will only run if the Action exists on the base commit
`94`		`- of a pull request, and it will run the Action version present on that`
`95`		`- commit, meaning we wouldn't be able to use it for already opened PRs`
`96`		`- without rebasing them first.`
`97`		`-`
`98`		`-The workflow starts with a small candidate job that uses GitHub CLI to fetch`
`99`		-open pull requests with the `commit-queue` label and without the `blocked`
`100`		`-label. It fetches two buckets: pull requests created at least two days earlier`
`101`		-and pull requests with the `fast-track` label. The job de-duplicates the
`102`		`-buckets before passing the candidates to the landing job. Pull requests in`
`103`		`-neither bucket remain labeled but are not processed during that run.`
`104`		`-`
`105`		`-If there are candidate PRs, the landing job installs and configures`
`106`		-`@node-core/utils` once with a personal token and a Jenkins token from
`107`		`-[@nodejs-github-bot](https://github.com/nodejs/github-bot). It then downloads`
`108`		`-the workflow commit's README without checking out the repository and runs`
`109`		-`git node metadata --readme --json` for each candidate. This uses the same
`110`		-`@node-core/utils` PR readiness checks as `git node land`, but does not clone,
`111`		`-fetch, or merge the PR. The filter consumes the structured metadata result`
`112`		`-and its exit code instead of matching human-readable output:`
`113`		`-`
`114`		-* exit code `0`: the PR is ready and is passed to
`115`		- [`commit-queue.sh`](../../tools/actions/commit-queue.sh)
`116`		-* exit codes `20`-`29`: the PR is not ready for a deferrable metadata reason,
`117`		- currently wait time, so it keeps the `commit-queue` label and is retried
`118`		`- later`
`119`		-* exit codes `40`-`49`: the PR has a hard or mixed metadata readiness failure
`120`		- and is passed to [`commit-queue.sh`](../../tools/actions/commit-queue.sh)
`121`		`-`
`122`		-The `20`-`29` exit code range is reserved by `@node-core/utils` for deferrable
`123`		-metadata readiness states, and `40`-`49` is reserved for hard metadata failure
`124`		`-states. Unknown filter failures fail the workflow before starting the landing`
`125`		`-script and leave PR labels unchanged so the queue can retry on a later`
`126`		-scheduled run. PRs passed through with exit code `40`-`49` continue through
`127`		-`commit-queue.sh`. The workflow checks out the repository only when at least
`128`		`-one PR remains after filtering. The script does not separately skip PRs with a`
`129`		-`request-ci` label or pending GitHub checks. Instead, `git node land` performs
`130`		`-the landing checks and the script reports any failure through the normal queue`
`131`		`-failure path.`
`132`		`-`
`133`		`-> The personal token needs permission for public repositories and to read`
`134`		-> profiles. It is used by `@node-core/utils` and by the landing job for
`135`		`-> checkout, label and comment updates, merging, and pushing. Jenkins token is`
`136`		`-> required to check CI status.`
`137`		`-`
`138`		-`commit-queue.sh` receives the following positional arguments:
`139`		`-`
`140`		`-1. The repository owner`
`141`		`-2. The repository name`
`142`		`-3. Every positional argument starting at this one will be a pull request ID of`
`143`		`- a pull request with commit-queue set.`
`144`		`-`
`145`		`-The script iterates over the pull requests. For each PR, it uses GitHub CLI to`
`146`		`-fetch the labels and select the multiple-commit policy, then runs`
`147`		-`git node land`, forwarding stdout and stderr to a file. It does not perform a
`148`		-separate CI preflight; `git node land` performs the current readiness and CI
`149`		`-validation.`
`150`		`-`
`151`		-The script keeps the `commit-queue` label in place while `git node land` is
`152`		`-running. PRs that are only blocked on wait time should have already been`
`153`		`-filtered by the metadata check. A hard or mixed readiness failure is passed`
`154`		-through so `git node land` can produce the failure output. If the landing
`155`		`-attempt fails for that or any other reason, the job replaces the`
`156`		-`commit-queue` label with `commit-queue-failed`, leaves a comment with the
`157`		`-output, and then aborts the landing session. If the abort fails, the queue`
`158`		`-stops instead of continuing in an unknown state.`
`159`		`-`
`160`		`-Fast-tracked PRs use the metadata check before checkout and the landing script.`
`161`		`-If the fast-track request has not yet received enough collaborator thumbs-up,`
`162`		-the queue keeps the `commit-queue` label and retries until either the
`163`		`-fast-track request is approved or the PR becomes landable through the regular`
`164`		`-wait-time rules. The commit queue does not create the fast-track request`
`165`		-comment; that is handled when the `fast-track` label is added. If that comment
`166`		`-is missing, the queue reports the failure instead of keeping the PR queued.`
`167`		`-`
`168`		-If no errors happen during `git node land`, the script either pushes the direct
`169`		-rebase landing to `main` or uses GitHub's squash merge API for single-commit and
`170`		-fixup landings. It then leaves a `Landed in ...` comment in the PR. GitHub
`171`		`-closes PRs merged through the merge API automatically; for direct pushes, the`
`172`		-script closes the PR. The script then removes the `commit-queue` label.
`173`		`-Iteration continues until all PRs have done the steps above.`
`174`		`-`
`175`		`-## Reverting broken commits`
`176`		`-`
`177`		`-Reverting broken commits is done manually by collaborators, just like when`
`178`		-commits are landed manually via `git node land`. An easy way to revert is a
`179`		`-good feature for the project, but is not explicitly required for the Commit`
`180`		`-Queue to work because the Action lands PRs just like collaborators do today. If`
`181`		`-once we start using the Commit Queue we notice that the number of required`
`182`		`-reverts increases drastically, we can pause the queue until a Revert Queue is`
`183`		`-implemented, but until then we can enable the Commit Queue and then work on a`
`184`		`-Revert Queue as a follow-up.`
	`34`	`+ as backport PRs, are ignored).`

Collapse file

`‎tools/actions/commit-queue.sh‎`

Copy file name to clipboardExpand all lines: tools/actions/commit-queue.sh

+9-17Lines changed: 9 additions & 17 deletions

Original file line number	Diff line number	Diff line change
`@@ -2,39 +2,31 @@`
`2`	`2`
`3`	`3`	`set -xe`
`4`	`4`
`5`		`-OWNER=$1`
`6`		`-REPOSITORY=$2`
`7`		`-shift 2`
`8`		`-`
`9`	`5`	`UPSTREAM=origin`
`10`	`6`	`DEFAULT_BRANCH=main`
`11`	`7`
`12`	`8`	`COMMIT_QUEUE_LABEL="commit-queue"`
`13`	`9`	`COMMIT_QUEUE_FAILED_LABEL="commit-queue-failed"`
`14`	`10`
	`11`	`+cqurl="${GITHUB_SERVER_URL:?}/${GITHUB_REPOSITORY:?}/actions/runs/${GITHUB_RUN_ID:?}"`
	`12`	`+`
`15`	`13`	`commit_queue_failed() {`
`16`	`14`	`pr=$1`
`17`	`15`
`18`		`- gh pr edit "$pr" --add-label "${COMMIT_QUEUE_FAILED_LABEL}" --remove-label "${COMMIT_QUEUE_LABEL}"`
	`16`	`+ gh -R "$GITHUB_REPOSITORY" pr edit "$pr" --add-label "${COMMIT_QUEUE_FAILED_LABEL}" --remove-label "${COMMIT_QUEUE_LABEL}"`
`19`	`17`
`20`		`- # shellcheck disable=SC2154`
`21`		`- cqurl="${GITHUB_SERVER_URL}/${OWNER}/${REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"`
`22`	`18`	`body="<details><summary>Commit Queue failed</summary><pre>$(sed -e 's/&/\&/g' -e 's/</\</g' -e 's/>/\>/g' output)</pre><a href='$cqurl'>$cqurl</a></details>"`
`23`	`19`	`echo "$body"`
`24`	`20`
`25`		`- gh pr comment "$pr" --body "$body"`
	`21`	`+ gh -R "$GITHUB_REPOSITORY" pr comment "$pr" --body "$body"`
`26`	`22`
`27`	`23`	`rm output`
`28`	`24`	`}`
`29`	`25`
`30`		`-# TODO(mmarchini): should this be set with whoever added the label for each PR?`
`31`		`-git config --local user.email "[email protected]"`
`32`		`-git config --local user.name "Node.js GitHub Bot"`
`33`		`-`
`34`	`26`	`SHOULD_ABORT=`
`35`	`27`
`36`	`28`	`for pr in "$@"; do`
`37`		`- gh pr view "$pr" --json labels --jq ".labels" > labels.json`
	`29`	`+ gh -R "$GITHUB_REPOSITORY" pr view "$pr" --json labels --jq ".labels" > labels.json`
`38`	`30`
`39`	`31`	`if jq -e 'map(.name) \| index("commit-queue-squash")' < labels.json; then`
`40`	`32`	`MULTIPLE_COMMIT_POLICY="--fixupAll"`
`@@ -87,7 +79,7 @@ for pr in "$@"; do`
`87`	`79`	`--arg body "${commit_body}" \`
`88`	`80`	`--arg head "${commit_head}" \`
`89`	`81`	`'{merge_method:"squash",commit_title:$title,commit_message:$body,sha:$head}' \|\`
`90`		`- gh api -X PUT "repos/${OWNER}/${REPOSITORY}/pulls/${pr}/merge" --input -\`
	`82`	`+ gh api -X PUT "repos/${GITHUB_REPOSITORY}/pulls/${pr}/merge" --input -\`
`91`	`83`	`--jq 'if .merged then .sha else halt_error end'`
`92`	`84`	`)"; then`
`93`	`85`	`commit_queue_failed "$pr"`
`@@ -97,12 +89,12 @@ for pr in "$@"; do`
`97`	`89`
`98`	`90`	`rm output`
`99`	`91`
`100`		`- gh pr comment "$pr" --body "Landed in $commits"`
	`92`	`+ gh -R "$GITHUB_REPOSITORY" pr comment "$pr" --body "Landed in $commits"`
`101`	`93`
`102`		`- [ -z "$MULTIPLE_COMMIT_POLICY" ] && gh pr close "$pr"`
	`94`	`+ [ -z "$MULTIPLE_COMMIT_POLICY" ] && gh -R "$GITHUB_REPOSITORY" pr close "$pr"`
`103`	`95`
`104`	`96`	`# Delete the commit queue label (but ignore errors, it's no big deal if a closed PR still has the label)`
`105`		`- gh pr edit "$pr" --remove-label "$COMMIT_QUEUE_LABEL" \|\| true`
	`97`	`+ gh -R "$GITHUB_REPOSITORY" pr edit "$pr" --remove-label "$COMMIT_QUEUE_LABEL" \|\| true`
`106`	`98`	`done`
`107`	`99`
`108`	`100`	`rm -f labels.json`

Collapse file

`‎tools/actions/start-ci.sh‎`

Copy file name to clipboardExpand all lines: tools/actions/start-ci.sh

+4-5Lines changed: 4 additions & 5 deletions

Original file line number	Diff line number	Diff line change
`@@ -4,9 +4,10 @@ set -xe`
`4`	`4`
`5`	`5`	`REQUEST_CI_LABEL="request-ci"`
`6`	`6`	`REQUEST_CI_FAILED_LABEL="request-ci-failed"`
	`7`	`+cqurl="${GITHUB_SERVER_URL:?}/${GITHUB_REPOSITORY:?}/actions/runs/${GITHUB_RUN_ID:?}"`
`7`	`8`
`8`	`9`	`for pr in "$@"; do`
`9`		`- gh pr edit "$pr" --remove-label "$REQUEST_CI_LABEL"`
	`10`	`+ gh -R "$GITHUB_REPOSITORY" pr edit "$pr" --remove-label "$REQUEST_CI_LABEL"`
`10`	`11`
`11`	`12`	`ci_started=yes`
`12`	`13`	`rm -f output;`
`@@ -15,14 +16,12 @@ for pr in "$@"; do`
`15`	`16`
`16`	`17`	`if [ "$ci_started" = "no" ]; then`
`17`	`18`	`# Do we need to reset?`
`18`		`- gh pr edit "$pr" --add-label "$REQUEST_CI_FAILED_LABEL"`
	`19`	`+ gh -R "$GITHUB_REPOSITORY" pr edit "$pr" --add-label "$REQUEST_CI_FAILED_LABEL"`
`19`	`20`
`20`		`- # shellcheck disable=SC2154`
`21`		`- cqurl="${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"`
`22`	`21`	`body="<details><summary>Failed to start CI</summary><pre>$(cat output)</pre><a href='$cqurl'>$cqurl</a></details>"`
`23`	`22`	`echo "$body"`
`24`	`23`
`25`		`- gh pr comment "$pr" --body "$body"`
	`24`	`+ gh -R "$GITHUB_REPOSITORY" pr comment "$pr" --body "$body"`
`26`	`25`
`27`	`26`	`rm output`
`28`	`27`	`fi`

0 commit comments

Comments

0 (0)

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.