zlacker

[return to "Automating a Software Company with GitHub Actions"]
1. BugsJu+Zf[view] [source] 2021-08-19 15:25:16
>>marius+(OP)
I love GH actions, but they're still a bit too sharp-edged for my taste.

Like...the last time I checked, workflows had no runtime macro for limiting execution to the default branch except explicitly by a specific name, and the closest you could get to generically checking "whatever the default branch is called right now" was either a template workflow that would set some static text for the name at creation that breaks if the default branch name is subsequently changed or a song and dance querying the API and setting an environment variable inside one of the workflow steps and then gating all subsequent steps on the result. This was a long time after they introduced editable default branch names and seems like such an obvious oversight.

Then there are weird quirks like the subshell file system permissions block that requires using sudo if you want to move files around within your repo clone from inside an invoked shell script.

◧◩
2. mtalan+Yk[view] [source] 2021-08-19 15:50:36
>>BugsJu+Zf
One relatively simple thing I'd love is the ability to re-run a job where it fails, which is something other CI systems have. On a current project we have some flaky Cypress tests and it sucks to have to re-run the entire workflow from the start when one of the last steps of the job fails. I'm definitely not the only one wanting this [1].

They also offer triggering workflows with 'workflow_run' based on other workflows, but that only happens on the default main branch. We auto build testing environments on each PR and I'd love to be able to have better workflow management based on branches.

[1] https://github.com/actions/runner/issues/432

◧◩◪
3. simonw+t31[view] [source] 2021-08-19 19:20:29
>>mtalan+Yk
Looks like someone has built a reusable action for retries: https://github.com/marketplace/actions/retry-step
[go to top]