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

101–110 of 111 posts

Re: GitHub Actions Pitfalls

#101

Post by naikrovek »

jacobyoder wrote: post #74
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…

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.

why would you change the clock and not the timezone? why would you even change the timezone?

Re: GitHub Actions Pitfalls

#102

Post by naikrovek »

WirelessGigabit wrote: post #35

Dear GitHub actions. I want &pointers so I don’t have to repeat myself. 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!

reusable workflows are a thing now. may not meet your needs, but it's something.

Re: GitHub Actions Pitfalls

#103

Post by naikrovek »

0xbadcafebee wrote: post #53
masklinn wrote: post #22

Earlier quoted context omitted.

You might be getting the string True because in Yaml 1.1 the scalars “y”, “n”, “yes”, “no”, “on”, and “off” (in all their casings) are Boolean literals. I believe YAML supports non-string keys, so your key would be parsed to the corresponding Boolean value (true), if the pipeline then goes through JSON where only string keys are supported the serialiser could simply stringing the key rather than raise an error, leadi…

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…

JSON is valid YAML, don't forget. you can always fall back to JSON if YAML gives you trouble.

Re: GitHub Actions Pitfalls

#104

Post by naikrovek »

silverwind wrote: post #84
ectopod wrote: post #33

Another surprise: "ubuntu-latest" is not the latest ubuntu! It is stuck at 20.04. If you want 22.04 you need to specify "ubuntu-22.04". Similar issue with macos-latest.

With 20.04, they were over a year behind when they finally updates the latest tag.

I suggest you follow the issues in that repo if you want to see why. it's difficult keeping the massive packer template they use in good shape.

https://github.com/actions/runner-images/

I rely on that repo to build my own images and it is a frequent cause of failed builds. I'm going to convert almost all of it to installation via homebrew instead, I think. works well for MacOS anyway.

Re: GitHub Actions Pitfalls

#106

Post by bilalq »

naikrovek wrote: post #100
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.

???

I'm not talking about using this on a free tier or something. Github actions are billed monthly. This goes way beyond just not having a tight SLA. Precision isn't even the ask here. It's one thing if a job scheduled to run every 10 minutes occasionally takes 12 or 13 in between runs. It's a completely different matter if it takes an hour.

Having some safe-guards against unbounded recursion is one thing, but the escape hatch for it right now is to use less secure credentials. That's just madness.

Re: GitHub Actions Pitfalls

#108

Post by phist_mcgee »

cmcconomy wrote: post #39

I now use a Makefile and put as much logic as I can in `make cicd` so I can call it in a single line, keeping the GitHub action as simple as possible.

+1 for Justfiles[1]! They're a much saner alternative to makefiles with great shell support

[1] https://github.com/casey/just

Re: GitHub Actions Pitfalls

#109

Post by FateOfNations »

naikrovek wrote: post #101
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.

why would you change the clock and not the timezone? why would you even change the timezone?

Because sometimes you want to change it to a date many months or years in the future. That kind of thing as a test to make sure nothing goes wrong based on the date, like Y2K/Year 2038, or malicious code that's designed to lay dormant until some point in the future.

Re: GitHub Actions Pitfalls

#110

Post by naikrovek »

FateOfNations wrote: post #109
naikrovek wrote: post #101

Earlier quoted context omitted.

why would you change the clock and not the timezone? why would you even change the timezone?

Because sometimes you want to change it to a date many months or years in the future. That kind of thing as a test to make sure nothing goes wrong based on the date, like Y2K/Year 2038, or malicious code that's designed to lay dormant until some point in the future.

that is a very naive way to go about that, i think, for reasons exactly like jacobyoder discovered. Seems to me that it would be much better to write code which allows you to override the time seen by your software by setting some delta specified in an environment variable or something, or by having test cases which test your logic without requiring that the notion of the current time be changed.

Changing the current time will do unknown things to other software running on the system, and there are too many question marks there for that to seem reasonable, to me.

Post reply on HN