Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions Pitfalls

fusectore.dev

Post reply on HN
Print view View original

91–100 of 111 posts

Re: GitHub Actions Pitfalls

#91

Post by jacobyoder »

dylan604 wrote: post #88
jacobyoder wrote: post #74

Earlier quoted context omitted.

Yet another pitfall: Changing the system clock on runners can throw off billing and calculation of used minutes. Colleague of mine told me about that one last year.

I'm guessing not in your favor either? I miss the days of setting the clock/date to avoid time bombs in software builds. "back in my day, things were so much easier!" now, I would not be surprised if the teams working on these kinds of lock outs are larger than the teams building the product.

Potentially, maybe? I didn't follow it closely enough, but the crux was a group trying to test out various time-related calls, and they'd set the base time of the containers to different times forward and behind 'now'. There were hundreds/thousands of minutes 'billed', going over the account threshhold, stopping all builds. But... I don't remember hearing if there was some diff between 'negative' charges and 'positive' charges.

Re: GitHub Actions Pitfalls

#92

Post by ruuda »

ekimekim wrote: post #80
0xbadcafebee wrote: post #53

Earlier quoted context omitted.

I once worked on a project where the input was YAML config files and a lot of different programs would read/write the files. Every different parser had at least one implementation-specific quirk. Often we would run into the quirks because someone edited the YAML by hand, and one parser would handle it fine, while another would barf. That's when I found out the YAML spec explicitly says it's human- readable , not huma…

I've hit problems where YAML generated by one implementation will hit parsing quirks in another implementation. Now my advice is: If you have something that consumes YAML, generate JSON and feed it that instead. YAML is defined to be a superset of JSON, and every implementation should be able to handle it fine. For those interested, the problem was with the string "08". At least at the time, the pyYAML generator I wa…

Yeah exactly, generate json instead. I now have some GitHub Actions config in Python, and some in Nix. Nix is actually really nice for this. Like yaml it has less line noise than json and it support comments, but unlike yaml the language is extremely simple without weird corner cases to make it "easier", and it has variables and functions so you can write reusable jobs.

Re: GitHub Actions Pitfalls

#93

Post by xani_ »

tomphoolery wrote: post #65

Set a global timeout for your jobs. Seriously. Think you don't need one? You're wrong. Set a global timeout for your jobs. Whoever pays that bill will thank you later. Private actions don't give a damn if `setup-node` is taking a whole hour to install Node. They don't care if your hosting service is having trouble and runs a deployment for 5 hours. You will be billed for that, and it adds up. Set a global timeout for…

Applies to pretty much every resource. Monitor, monitor, monitor, then alert at the very least on thresholds, preferably on anomalies.

Re: GitHub Actions Pitfalls

#94

Post by marcosdumay »

xani_ wrote: post #93
tomphoolery wrote: post #65

Set a global timeout for your jobs. Seriously. Think you don't need one? You're wrong. Set a global timeout for your jobs. Whoever pays that bill will thank you later. Private actions don't give a damn if `setup-node` is taking a whole hour to install Node. They don't care if your hosting service is having trouble and runs a deployment for 5 hours. You will be billed for that, and it adds up. Set a global timeout for…

Applies to pretty much every resource. Monitor, monitor, monitor, then alert at the very least on thresholds, preferably on anomalies.

The GP is more on the lines of limiting, not monitoring.

Re: GitHub Actions Pitfalls

#95

Post by [deleted] »

kilroy123 wrote: post #52
sandreas wrote: post #3

If you want to run github actions locally before any pitfalls, you can try out https://github.com/nektos/act

Have folks had good success with using this? For me it was extremely slow and it was far faster to just push a branch to github and test.

[deleted]

Re: GitHub Actions Pitfalls

#96

Post by tjoff »

tomphoolery wrote: post #65

Set a global timeout for your jobs. Seriously. Think you don't need one? You're wrong. Set a global timeout for your jobs. Whoever pays that bill will thank you later. Private actions don't give a damn if `setup-node` is taking a whole hour to install Node. They don't care if your hosting service is having trouble and runs a deployment for 5 hours. You will be billed for that, and it adds up. Set a global timeout for…

Or, just don't run pipelines in the cloud with all the payment anxiety it brings.

Re: GitHub Actions Pitfalls

#97

Post by hobo_mark »

anakaiti wrote: post #44
philshem wrote: post #15

Earlier quoted context omitted.

And for gitlab pipelines: https://stackoverflow.com/q/32933174

Unfortunately, it only supports running single jobs. More complex tasks that requires dependencies, variables, job creation context (MR, Trigger, Web, etc.) can't be tested.

Then maybe this?

https://github.com/firecow/gitlab-ci-local

(I only tried it shortly many months ago before running into some issues, it probably works better now)

Re: GitHub Actions Pitfalls

#98

Post by horse666 »

There’s an awkward gotcha/incompatibility between “Required status checks” and workflows that get skipped [1], eg due to setting a “paths” property of a push/pull_request workflow trigger [2].

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-...

[3]: https://github.com/dorny/paths-filter

Re: GitHub Actions Pitfalls

#99

Post by louislang »

Docker request limits are kind of a pain to deal with in Github Actions. This recently bit us, and no amount of logging into a _paid_ docker account would rectify the problem.

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.

Re: GitHub Actions Pitfalls

#100

Post by naikrovek »

bilalq wrote: post #63

A few other pitfalls: * 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 re…

don't rely on public infrastructure of unknown usage to do scheduled tasks of precise execution time is required. public GitHub runners offer few guarantees.

I welcome their anti-recursion measures because I fought in the recursive clone wars and no one should have to support any systems that allow that.

Post reply on HN