rerun: rebuild workflow

[bevanjkay]

This is a start on a workflow to allow scheduled re-running, and triggered re-running of CI suites on PRs.

There's a few things to get sorted before this is ready (if the approach is ok)

• Make the code less repetitive (potentially split the collecting of PRs, and the re-running into different steps)
• Handle CI runs that are already in progress (they may need to be cancelled before they can be rerun)

[Bo98]

Perhaps could do with detailing what you are looking to do here. There's a solution here but there's no description of what the problem is. In what scenarios are you needing this and how is GitHub's retry button not suitable for those?

It also seems like a lot of copy-pasting (as you've acknowledged). Why do we need all of ci-retry, ci-retry-failed-jobs, ci-requeue and ci-requeue-failed-jobs? What scenarios are each of them used in?

[bevanjkay]

Thanks for having a look @Bo98 - I should have explained a bit further but was just dumping the progress here for now.

This is designed to be a replacement for an action that was recently removed, as it sat outside of our organisational scope.
https://github.com/Homebrew/homebrew-cask/blob/63761587c8da941038d618e3c3da4b03888abdc8/.github/workflows/rerun-workflow.yml
Removed in: #179541

ci-retry (via a label) was used in cases where we are waiting on upstream changes (for example global cdn propagation), so tests are re-run on a 3-hour interval systematically.
ci-requeue just reruns the suite, but is potentially not necessary as the GitHub UI provides this possibility fairly easily.

The *-failed-jobs is a variant that only retries the failed jobs and not the whole suite.

There was also logic to automatically re-run the suite if certain labels were added, such as ci-syntax-only, without having to manually rerun the generate-matrix job.

[carlocab]

Let's avoid interpolating right into a shell script, see https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable.

Suggested change

	PR_NUMBER=$(gh pr view "${{ github.event.pull_request.number }}" --json headRefName --jq '.headRefName')
	WORKFLOW_RUN_ID=$(gh pr view "${{ github.event.pull_request.number }}" --json headRefName --jq '.headRefName' | xargs -I {} gh run list --workflow=ci.yml --branch={} --json databaseId,status --jq '.[].databaseId')
	if [ -n "$WORKFLOW_RUN_ID" ]; then
	echo "Rerunning workflow run #$WORKFLOW_RUN_ID for PR #$PR_NUMBER"
	gh run rerun "$WORKFLOW_RUN_ID"
	else
	echo "No runs found for PR #$PR_NUMBER"
	fi
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	PR_NUMBER=$(gh pr view "$PULL_REQUEST_NUMBER" --json headRefName --jq '.headRefName')
	WORKFLOW_RUN_ID=$(gh pr view "$PULL_REQUEST_NUMBER" --json headRefName --jq '.headRefName' | xargs -I {} gh run list --workflow=ci.yml --branch={} --json databaseId,status --jq '.[].databaseId')
	if [ -n "$WORKFLOW_RUN_ID" ]; then
	echo "Rerunning workflow run #$WORKFLOW_RUN_ID for PR #$PR_NUMBER"
	gh run rerun "$WORKFLOW_RUN_ID"
	else
	echo "No runs found for PR #$PR_NUMBER"
	fi
	env:
	GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
	PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number }}

I also don't really follow what's going on with PR_NUMBER and WORKFLOW_RUN_ID. The content of PR_NUMBER won't be a pull request number, will it?

[carlocab]

Do you need this? I don't think you do anything about closed PRs below.

[bevanjkay]

This is a leftover from the previous workflow that I started with. I will remove it.

[carlocab]

Given that this is run on a schedule, should we also automatically remove some of these labels at some point?

[bevanjkay]

Historically, ci-retry runs until it is removed or CI passes (I just haven't written the logic to remove the label yet). ci-requeue is removed immediately, but based on the discussion this will likely get removed entirely in lieu of just running using the UI.

[carlocab]

It seems weird to run this also on unlabeled events.

[bevanjkay]

This is another carryover from the previous action. If you removed a label such as ci-syntax-only or ci-skip-install the suite would automatically be re-run as the current CI state would no longer correlate with the applied labels.

[carlocab]

Try to use long flags where they're available for readability.

Suggested change

	PR_NUMBERS=$(gh pr list -l 'ci-retry' --json number --jq '.[].number')
	PR_NUMBERS=$(gh pr list --label 'ci-retry' --json number --jq '.[].number')

This may need to be done elsewhere too.

[carlocab]

Might be cleaner to do something like this:

Suggested change

	if: >
	github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
	if: contains(fromJSON('["schedule", "workflow_dispatch"]'), github.event.name)

See https://docs.github.com/en/actions/learn-github-actions/expressions#example-matching-an-array-of-strings

[carlocab]

Suggested change

	if: >
	github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
	if: contains(fromJSON('["schedule", "workflow_dispatch"]'), github.event.name)

[carlocab]

Suggested change

	if: >
	(
	github.event.label.name == 'ci-syntax-only' ||
	github.event.label.name == 'ci-requeue' ||
	github.event.label.name == 'ci-skip-install'
	)
	if: contains(fromJSON('["ci-syntax-only", "ci-requeue", "ci-skip-install"]'), github.event.label.name)

[Bo98]

The *-failed-jobs is a variant that only retries the failed jobs and not the whole suite.

Is there any reason why you wouldn't always do this for ci-retry?

[bevanjkay]

Is there any reason why you wouldn't always do this for ci-retry?

This is a good suggestion thanks. I think it makes sense to update ci-retry to only re-run the failed jobs.

[bevanjkay]

Thanks for the feedback everyone, I think the logic for this is going to be too complicated to build into the action directly, so will require some external functions added in Homebrew/actions.