Hacker News Reader

Comment by orf | Hacker News Reader

Why does forking cause a GitHub actions schedule to run? This is pretty unexpected.

I wonder what % of actions builds are useless runs like this?

Edit: to the shadowbanned guy who hasn’t realised he’s been shadowbanned for years, that’s not correct.

It's the reason you get random build failure notifications and warning emails that your (free) credits are running out, etc..

Took me a while to figure out what happened the first time I ran into this.

It’s a cron workflow

Yes?

Why would you expect a cron task to work differently because a repo is a fork or not? Maybe Actions/Workflows shouldn’t be enabled by default on forks, which used to be the case but that has its problems too. You can disable actions on your forks.

Why would I expect pressing the fork button would suddenly enable redundant and, in aggregare, expensive cronjobs?

Most people fork to make a pull request and then never delete the fork after. Why are any scheduled actions required for that?

It depends on how you use the fork and what you use it for. That’s up to the project to decide, not GitHub. Most workflows are triggered on an update-event, like git push or create a tag or branch or pull request etc. You want them to trigger on your fork separately from the main repo because (a) the secrets aren’t shared between forks and main repo (b) you want to catch linters, automated tests, build issues and all the other things workflows are used for before you create a pull request if possible.

Cron tasks are the odd exception. You can use them to update dependencies in your repo, or track an external dependency and rebuild your stuff with it, or nightly integration tests with external APIs, etc.

Maybe they could enable all actions but cron actions, but then that’s just as equally confusing. I’d rather GitHub stay out of deciding what’s “expensive” and what’s not. Either enable all actions on forks by default, or disable them by default. They decided to enable them by default and give each user however many minutes of free actions time. I’m sure there is a better upsell opportunity there too.

Would you say the percentage of total forked repos that benefit from (or are even aware of) scheduled actions is less or more than 0.001%?

The problem of concurrent cron jobs isn't new. Solutions existed for decades. Fedora cron used eth0's first IP address and a urandom number to stagger cron jobs starting times. Google addressed this issue by having a single enterprise wide cron service. Why does Github have such a simplistic cron service in this day and age?

> Fedora cron used eth0's first IP address and a urandom number to stagger cron jobs starting times.

What?

> Google addressed this issue by having a single enterprise wide cron service.

What???

What does any of that even mean my guy? Neither of these were a cron CI shell script services. What does any of that even mean? Did you just read the word “cron” and get excited?

I understood the issue was caused by lots of cron jobs firing at the same moment. If Github had a better cron, the 700 or whatever network downloads would not have occurred at the same moment and there would have been no problem. Sorry if I misunderstood something.

Reply on news.ycombinator.com