Live data from Hacker News

GitHub Actions Pitfalls

fusectore.dev

61–70 of 111 posts

Re: GitHub Actions Pitfalls

#61
post #9

Also a fun one is the "on" key that specifies when the workflow should run. "on" is magic in yaml, and some implementations will convert it to the string (!) "True" when it occurs as a key (I'm not talking about values here). This was a bit confusing when I tried to replace a hand-written yaml with a generated json ... They were identical, except for the on/True key. It's still not clear to me whether this is accordi…

> "True" when it occurs as a key (I'm not talking about values here).

In fact, YAML does that terrible substitution for both keys and values.

Re: GitHub Actions Pitfalls

#62

I believe pull request from forks are not triggered by default because some people where using this to mine cryptocrap on cpu using the quotas of other projects.

Ya, while this restriction makes sense it does mean that you have to jump through a few weird hoops to get Fork based workflows to allow commenting on pull requests from the action

Re: GitHub Actions Pitfalls

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

Re: GitHub Actions Pitfalls

#64

The UI for seeing logs is driving me insaaaane. It's extremely slow and sluggish. Sometimes you have to refresh the page to see the actual latest line of the log.

also normal search doesn't work, you have to use the in-UI JS search widget.

Pressing ctrl-f twice works (not that it's good UX)

Re: GitHub Actions Pitfalls

#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 your jobs.

Re: GitHub Actions Pitfalls

#66

I believe pull request from forks are not triggered by default because some people where using this to mine cryptocrap on cpu using the quotas of other projects.

Quoted post unavailable.

> my chance at a growth industry

I think your view on of crypto might be skewed by this. I think working in coal or surveillance tech or fracking is bad, and that isn't changed by the fact that it is someone's best chance at getting rich from it.

Note that most programmers didn't get rich out of social media or the boom from the last decade: maybe 100,000 became millionaires out of 20 million programmers, most of whom had generally middle class salaries

Re: GitHub Actions Pitfalls

#67
post #29

Earlier quoted context omitted.

I think that's called whataboutism.

When picking a potential employer, programmers often think "what about Google?" or "what about Facebook?" or "What about the hottest a16z startup?". When those programmers then compare/contrast the behavior of the companies they're considering, it is not considered a logical fallacy, but "making a list of pros/cons." If I am going to trade my time and energy for money, I think it's fair to compare my options, and not…

You're completely missing the point of my comment. You say "crypto is not as bad as facebook" which is a textbook whataboutism. "crypto" isn't as bad as the Shoah, so what?

Re: GitHub Actions Pitfalls

#68

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…

I can feel the bitter experience in your writing! Ditto.

Re: GitHub Actions Pitfalls

#69
We have a new integration at Cronitor to fully monitor your GitHub actions - works with both hosted and self-hosted runners. This is in beta right now. If anybody would like to check it out, let me know, Shane at cronitor

Re: GitHub Actions Pitfalls

#70

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…

Is there a way to set a global timeout now? Last I checked, you could only set them per job, i.e. you have to copy-paste "timeout-minutes: 15" to every single job in every single workflow in every single repo, and hope you didn't miss one. That's been the case for years[1] and a quick search shows it's still true[2]

The cynic in me thinks they like having the extra revenue.

[1] https://github.com/orgs/community/discussions/25472

[2] https://github.com/orgs/community/discussions/10690

Post reply on HN