3 ms·

Yes?

by orf 3y ago

Yes?

eddythompson80 3y ago
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.
- orf 3y ago
  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?
  - eddythompson80 3y ago
    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.
    - orf 3y ago
      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%?
- wpollock 3y ago
  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?
  - eddythompson80 3y ago
    > 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?
    - wpollock 3y ago
      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.

Yes?

by orf 3y ago

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.

orf 3y ago
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?
- eddythompson80 3y ago
  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.
  - orf 3y ago
    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%?
wpollock 3y ago
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?
- eddythompson80 3y ago
  > 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?
  - wpollock 3y ago
    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.