5 ms·
GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis. Let's start with the first and simpl
by stickfigure 5y ago
GitHub Actions has a lot of basic usability issues, none of which are fatal but all of which irritate me on a daily basis.
Let's start with the first and simplest: Why did my build fail? You'd think this should be front and center. Yet, the UX is "click through a couple links, then wade through thousands of lines of log output". In practice this is "download the logs and grep them for text strings like FAILURE".
The only way we've made this livable is by writing action code that sends test failures to a slack channel, and more or less ignoring the GitHub UI.
Second usability issue: Restarting a build. Happens all the time because of some flakey third-party service. It's pretty much my primary interaction with the GitHub Actions UI.
1. Click on build name
2. Click on "Re-run jobs" which brings down a dropdown menu
3. Click on "Re-run failed jobs" menu item
4. Click on "Re-run jobs" button on the confirm dialog
Seriously, after five times going through this flow I'm screaming for a JUST RERUN THE FUCKING JOBS ALREADY button. What's annoying is that this used to be better - the dropdown and confirm dialog are recent additions. The UX is degenerating.
The irony is that we migrated from CircleCI because they were screwing up their UX, and we figured GitHub would make something better... sigh.
- saurik 5y agoFWIW, 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.
- longcommonname 5y agoFor 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.
- booi 5y agoI 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.
- saurik 5y agoOh 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.
- OJFord 5y agoIf 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.
- savanaly 5y agoThis 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.
- hamandcheese 5y agoWhy have one button? Why not one button for the workflow, plus one button next to each job? Buildkite gets this right.
- ajkjk 5y agoI 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.
- jbmsf 5y agoI don't agree. I've used other CI platforms that get UX a lot more right.
- fivea 5y ago
- bastardoperator 5y agoWhy would you want to context shift to a UI anyways? I would argue slack is a better place to get notifications.
- gregmac 5y ago> 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.
- runeks 5y ago> 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).
- gregmac 5y ago> 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.
- fivea 5y ago> 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.
- deleted 5y ago[deleted]
- AHTERIX5000 5y agoMy 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.