3 ms·

We recently discover that if the last person to change cron schedule of the workflow is removed from the organization, workflow fails with cryptic errors.

by demaga 2y ago

We recently discover that if the last person to change cron __schedule__ of the workflow is removed from the organization, workflow fails with cryptic errors. It turns out, the last person to change cron __schedule__ (not the workflow file in general) is an 'actor' associated with this workflow. Very, very confusing implementation. Error messages are even more confusing - workflow runs are renamed as "{Unknown event}" and the message is "Email is unverified". Link to docs: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows https://docs.github.com/en/actions/writing-workflows/choosin...

joshstrange 2y ago
Things like this are why I hate having to use PATs in workflows. What if I leave the company? I’ll leave a wake of broken actions in my wake. I do not like that at all, a huge point of CI/CD is automation, reproducibility, and NOT being dependent on specific developers/machines.
- quesera 2y ago
  I believe this is a good use for a GitHub machine account. IIRC, GitHub recommends this practice in their docs, with a username of "YOUR_USERNAME-machine". The machine user is just an ordinary GitHub user, added as a member of the organization, with all the necessary repo permissions, and a generated access token added to the GH repo Secrets. The organization owner then manages this GH machine account as well as the org, and their own personal (or work) login account.
  - anttiharju 2y ago
    Using machine/service accounts across an org can (relatively) easily hit rate limits, better way is to use a github app instead for generating the tokens: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens https://github.com/peter-evans/create-pull-request/blob/main...
    - quesera 2y ago
      Good to know, thanks. We have not hit any rate limiting so far, but we're a relatively small team -- a dozen devs, a few hundred commits per day that trigger CI (we don't do CD), across half a dozen active repos.

We recently discover that if the last person to change cron __schedule__ of the workflow is removed from the organization, workflow fails with cryptic errors.

by demaga 2y ago

joshstrange 2y ago

Things like this are why I hate having to use PATs in workflows. What if I leave the company? I’ll leave a wake of broken actions in my wake. I do not like that at all, a huge point of CI/CD is automation, reproducibility, and NOT being dependent on specific developers/machines.

quesera 2y ago
I believe this is a good use for a GitHub machine account. IIRC, GitHub recommends this practice in their docs, with a username of "YOUR_USERNAME-machine". The machine user is just an ordinary GitHub user, added as a member of the organization, with all the necessary repo permissions, and a generated access token added to the GH repo Secrets. The organization owner then manages this GH machine account as well as the org, and their own personal (or work) login account.
- anttiharju 2y ago
  Using machine/service accounts across an org can (relatively) easily hit rate limits, better way is to use a github app instead for generating the tokens: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens https://github.com/peter-evans/create-pull-request/blob/main...
  - quesera 2y ago
    Good to know, thanks. We have not hit any rate limiting so far, but we're a relatively small team -- a dozen devs, a few hundred commits per day that trigger CI (we don't do CD), across half a dozen active repos.