This is why UI is hard. In a parallel universe they made the re-run jobs button like you want, and there's some person at the top of the Hacker News comments in that universe making the complaint that it's too hard to tell what the buttons do, and that only the common path of rebuilding failed builds is easy and once you need to do something uncommon it becomes irritatingly complex.

> This is why UI is hard.

Is it though?. I mean, pretty much all mainstream CICD services do this right out of the box. GitLab does this so well it's even totally transparent and never an issue.

How come GitHub actions, which succeeded all of its alternatives, managed to turn a solved problem into a constant source of headaches?

have you ever seen a simple microsoft product?

I dunno. In my experience UI is hard because some PM decided to start switching everything around, citing some engagement metric that seems to go up, even though it's obvious to everybody that it's a bad idea at a human level.

Why have one button? Why not one button for the workflow, plus one button next to each job?

Buildkite gets this right.

I don't agree. I've used other CI platforms that get UX a lot more right.

Which ones?

GitLab, Travis, circleci, Jenkins, AWS CodePipeline, etc etc etc

In fact, I cannot come up with a single CICD service which fails at this, except GitHub.

Circleci

> because of some flakey third-party service

I've started building in auto retries to the CI scripts for this type of thing, at least once it annoys me to a certain extent. The most glaring and unavoidable ones that come to mind across several projects are external certificate time stamping services.

I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems. But at the same time, it just isn't possible to get to 100% and retry is a better band-aid than constant human intervention.

> I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems.

I disagree. Retry mechanisms is mandatory for any network request. You cannot expect a message to travel across the globe on a wire without ever failing.

I would say the opposite: you must have a retry mechanism for all requests performed by your application; unless it’s acceptable to pass on this failure to the client (who will retry the request).

> I disagree. Retry mechanisms is mandatory for any network request. You cannot expect a message to travel across the globe on a wire without ever failing.

Actually good point, and I agree. I didn't state that well. What I was thinking of was some other things in builds I've seen retries be the band-aid for: flaky, timing-based unit tests; locked files/directories; or applying database migrations. My usual reaction to adding a retry to a build step is "no, let's fix the actual problem". Network requests to external services are a special case though, and absolutely should always have retries.

> I generally hate this type of thing: retry mechanisms are a lazy band-aid that can mask real problems.

They can, but beyond the old "it broke once it deployed" obvious pattern, 9 out of 10 times retries only sidestep basic nuisances from transient errors such as a request timing out.

FWIW, while the UI for re-running jobs used to be better, the result was a LOT worse as it would re-run all the jobs instead of just the failing ones, so I am still MUCH happier with the new flow ;P.

I feel like those are not mutually exclusive. The button could say "Rerun failed jobs" no confirmation with a small ▼ next to it that has the other "rerun all jobs" drop down.

Oh yeah: I am not intending to mean that the new UI is good, only that it is still somehow better than the old flow ;P.

For the majority of my pipelines I rerun from the start. The pipeline itself is idempotent, I don't care about each step and I much rather have a clean run than a fast run.

If you're already putting your own frontend on it in Slack, you could add a 're-run' button to that failure notification that hits the API for that? (I assume there is one.)

There's a weird DSL for buttons/layout in Slack, but it works, and obviously it's pretty easily testable, just fire the examples at your own endpoint and tweak it until it does what you want.

My own main frustration with Actions is just that the docs are bad, making it hard to configure.

My favorite issue is that when the service is down it just doesn't run jobs or notify in any way that they are not being run. No "error" state in PR view or anything, let's just skip tests.

Why would you want to context shift to a UI anyways? I would argue slack is a better place to get notifications.