Ability to restart individual GitHub Actions CI builds

[gvanrossum]

The cpython project runs a large number of CI jobs using Actions. Sometimes our tests are flaky and one job fails for a spurious reason (classic: ssl host not found). Of course we should fix our tests, but in the meantime it would be nice if we could restart just the failing job, rather than restarting all jobs (which we can force by closing and reopening the PR).

Is this on the roadmap? I recall this being possible (at least for privileged users) in some competing systems, like Travis-CI.

[akien-mga]

Related ticket on @actions: actions/runner#432

[miskander]

Thanks for the feature request, it's definitely on the roadmap and coming in the next few months!

[alexcnichols]

The ability to re-run a single job, and other re-run related improvements, are now on the public roadmap.

• Actions: Re-run improvements github/roadmap#271

[michhyun1]

Any update on the progress? It's March now, and I'm eagerly awaiting this feature

[Omzig]

Any update on the progress? It's March now, and I'm eagerly awaiting this feature

Looks like:

[OmerGery]

feature is live 🚀

[OmerGery]

Is there a tutorial? How do I re-run an individual job from the UI?

thats it re run from failed

[OmerGery]

@Snojo does any of your stuff use the needs: parameter?

works for me with :needs - re runs from failed

[yakirm-cr]

Is there a tutorial? How do I re-run an individual job from the UI?

thats it re run from failed

Re-running workflows and jobs (in GitHub Docs)

[piotrekkr]

Thanks for this 🙏 Great job 👍 I have a request with my use case that seems connected to this and I wrote it here: actions/runner#432 (comment) Should I create new feature request? Thanks again

[brookemitchell]

🏆 showed my team and shared the joy when we saw this 😆 🥇

[ethomson]

We've shipped the ability to re-run failed and individual jobs in a workflow! 🚢

[pragmaticivan]

Hi @ethomson just making sure, will that close github/roadmap#271 ? Because I think we still need the ability to re-try individual jobs for deployments with an environment.

Currently using a workaround where the deployment job is a full workflow that is triggered by another workflow and that's not a great DX yet ;/

[ethomson]

I was mistaken - as part of this, you should also be able to re-run individual jobs - please let me know if it doesn't work for you!

[pgregorr-amazon]

Hi @ethomson. I don't see the button to re-run individual jobs in my UI. . Are we missing some permissions? I had to get my other colleague (sharadb-amazon) to rerun this job for me.

https://github.com/project-chip/connectedhomeip/actions/runs/8559429860/job/23460693558

[JohnLBergqvist]

@ethomson Hi, I've noticed that if any of the dependent jobs further down the chain use reusable workflows, then attempting to re-run a failed job will fail with a GitHub Actions has encountered an internal error when running your job. message for the job it's just attempted to re-run. So currently, because I use reusable workflows, I'm unable to make use of the ability to re-run single jobs.

[ethomson]

Thanks for letting me know, I'll let the team know.

[chrispat]

We are working on it, it has something to do with duplicate job names across the workflows, at least in one case that we know of.

[melissachang]

Thanks for this feature. However, it's annoying that something that used to take 1 click, now takes 3 clicks.

Before:

• Click Re-run all jobs

After - Rerun failed jobs option

• Click Re-run jobs drop-down
• Click Re-run failed jobs option
• In confirmation dialog, click Re-run jobs button

After - Rerun all jobs option

• Click Re-run jobs drop-down
• Click Re-run all jobs option
• In confirmation dialog, click Re-run jobs button

Could we skip the confirmation dialog:

• If user selected Re-run all jobs. We're running all jobs like before this feature, we don't need a dialog to repeat the jobs we already see.

• If user selected Re-run failed jobs and only failed jobs are rerun. See previous screenshot. We already know the failed jobs, we don't need them repeated in the dialog.

[ethomson]

Thanks for the feedback, I'll pass it along to the team.

[JohnLBergqvist]

My only other piece of feedback is that I have to wait until all other running jobs have finished, before I can re-run my failed job. It would be nice to be able to re-run an individual failed job as soon as it fails, without having to wait for the rest of the run to finish.

[khitrenovich]

+1 on that, and it was also mentioned couple of times on the relevant issue (one, two)

[lobsterkatie]

Another +1. Re-running the job as soon as it fails would be the best solution, but I'd settle for a "Cancel workflow & rerun failed jobs" button. As it stands, I have to do those two steps individually, which would be annoying but ultimately fine if cancellation were instantaneous, but it isn't, so I have to wait around for the cancellation to take before I can then perform the three-step process described by @melissachang above. (+1 on that feedback as well, BTW. But for the record, I actually was psyched when this feature was released, so +1 to @DamienDennehy, too! 🙂 )

[janpio]

I created a separate discussion for this, I have the feeling comments in already "solved" discussions do not get much attention: https://github.com/orgs/community/discussions/73156 Leave an upvote or reaction over there!

[DamienDennehy]

Just wanted to say thank you for this. I've been waiting for it for two years, and it was holding up our ability to move to Actions from another service. It really is a game changer for us.

[GMNGeoffrey]

I really wish this allowed rerunning a job before the workflow finished. There were a couple of comments in the linked issue in the runner repository with the same request. I think this could still work with the model GitHub actions has where "attempts" are at the workflow level, but attempts would have to be allowed to proceed in parallel. Since rerunning a failed job also reruns all of its dependent jobs, any in-process runs of those jobs would be cancelled (they would normally have already failed, but they could have always() set). The other jobs still running or queued must not depend on the job that needs to rerun, so there should be no conflict, unless they're using artifacts it produces or something without declaring it in their dependencies (needs block), which is already a race and should probably just be undefined behavior.

[robinimplicit]

Definitely, having to wait for the workflow to finish is strange and is a missed feature for faster CI.

[janpio]

I created a separate discussion for this, I have the feeling comments in already "solved" discussions do not get much attention: https://github.com/orgs/community/discussions/73156 Leave an upvote or reaction over there!

[Omzig]

@OmerGery Can we change the tag to "partially shipped"?