by rethab on 9/25/22, 10:32 AM with 103 comments
by tomphoolery on 9/26/22, 3:53 PM
by sandreas on 9/26/22, 11:21 AM
by speedgoose on 9/26/22, 12:22 PM
by ducktective on 9/26/22, 11:52 AM
by bilalq on 9/26/22, 3:36 PM
* Scheduled actions basically never run anywhere close to on schedule. If you schedule something to run every 13 minutes, it may just run 1-3 times an hour with random 30 minute to 1 hour waits in between executions.
* Triggering a workflow as a result of an action from another workflow doesn't work if you're using the GITHUB_TOKEN as part of the action. Github does this to prevent accidental recursion, but it forces you to either use insecure PATs or rearchitect how to handle chained events: https://docs.github.com/en/actions/using-workflows/triggerin...
by pydry on 9/26/22, 12:32 PM
As much intelligence as possible ought to be pushed down to and tested and debugged on the script level so that you're left with little more than a linear sequence of 4-5 commands in your YAML.
The debugging tooling on github actions is, frankly, abysmal. You need a third party ngrok action to even run ssh.
by cmcconomy on 9/26/22, 2:26 PM
by WirelessGigabit on 9/26/22, 2:15 PM
Also, I like that you build the hypothetical merge of branch + main. But that commit SHA is gone after that successful build. Give me a way to track this. I need to store artifacts related to this build, as I don’t want to build those again!
by ruuda on 9/26/22, 11:57 AM
by zufallsheld on 9/26/22, 10:29 AM
In New projects I tend to use scripts to perform any required task for the ci and have github actions only run the script. Way easier to reason about.
Gitlab CI definitely handles this better with it "script" concept.
by ryan-duve on 9/26/22, 11:51 AM
1. for Github to natively allow CI management for several repos in a centralized way, so repo setup can just be "select this CI config" instead of "copy this YAML file and change the project name in some places"
2. to mandate certain CI steps at the organization level (such as running `black`) so it isn't opt-in
by darthcloud on 9/26/22, 11:55 AM
by gscho on 9/26/22, 12:42 PM
- [1] https://github.com/actions-runner-controller/actions-runner-...
by dtmtcm on 9/26/22, 2:10 PM
I'm 100% sure they don't use this internally as these are glaring issues that impacts anyone using the self hosted runner. They also recommend running the container as root[1] instead of designing something more secure and sane.
1: https://github.com/actions/runner/issues/434#issuecomment-61...
by horse666 on 9/26/22, 9:18 PM
The checks associated with the workflow don’t run and stay in a pending state, preventing the PR from being merged.
The only workaround I’m aware of is to use an action such as paths-filter [3] instead at the job level.
A further, related frustration/limitation - you can _only_ set the “paths” property [2] at the workflow level (i.e. not per-job), so those rules apply to all jobs in the workflow. Given that you can only build a DAG of jobs (ie “needs”) within a single workflow, it makes it quite difficult to do anything non trivial in a monorepo.
[1]: https://docs.github.com/en/repositories/configuring-branches...
[2]: https://docs.github.com/en/actions/using-workflows/workflow-...
by ripperdoc on 9/26/22, 7:13 PM
Of course, the nature of running various commands on virtual machines and shells is inherently messy, but GHA could have done a lot to hide that. Instead I feel like I'm forced mix YAML, bash, Powershell and various higher-level scripting languages (that came with the projects) in an unholy concoction that is hard to get right (return codes, passing values and escaping directly comes to mind) and that is even harder to debug, due to the nature of running somewhere else (act helps, a little, but it doesn't properly replicate the GHA environment).
I kind of wished I could write all my workflows cross-platform from start with some well known but fullfledged scripting language. (Which of course I could, and just use GHA to call that script). What options are out there to make this whole thing less brittle?
by ectopod on 9/26/22, 2:13 PM
by notrob on 9/26/22, 5:40 PM
> While this behavior can be changed by passing ignoreReturnCode as the third argument ExecOptions, the default behavior is very surprising.
This is the same behavior as node's child process exec when wrapped by util.promisify[1] If something returns a promise (async func) it should be expected that it has the possibility of being rejected.
[1] https://nodejs.org/api/child_process.html#child_processexecc...
by rhysd on 9/26/22, 12:43 PM
https://github.com/rhysd/actionlint
> oops.yaml:20:24: property "jobone" is not defined in object type {jobtwo: {outputs: {}; result: string}} [expression]
by m12k on 9/26/22, 1:31 PM
by louislang on 9/26/22, 10:17 PM
As it turns out, images are pulled at the start of the run, which means your docker login will have no effect if you're currently bumping into these pull limits. This is made worse by the fact that the images themselves are controlled in the remote actions you're using, not something in your own codebase.
So you're left with either: forking the action and controlling it yourself, or hoping the maintainer will push to the Github registry.
by richardfey on 9/26/22, 2:01 PM
by newman314 on 9/26/22, 5:12 PM
For example, I'd like to build an action that triggers a documentation update based on the path and filename that is changed.
on:
push:
branches:
- main
paths:
- */README.md
by encoderer on 9/26/22, 4:18 PM