4 ms·

Could you elaborate a bit on what you don't like about GH Actions? Just curious as I have a lot of experience with Gitlab CI and relatively less with GH Actions

Could you elaborate a bit on what you don't like about GH Actions? Just curious as I have a lot of experience with Gitlab CI and relatively less with GH Actions.

smcleod 3y ago
Oh gosh where do I even start. Actually, I was recently writing up a list of issues that the teams I work with have with it the other day. I'll share it here however I'll have to post an update to later as it's missing one of my sources. Github is aware of (and somewhat accepts) every one of these items. -There are frequent outages (several times a week, sometimes daily) to Github Actions APIs that result in people having to retry workflows that are stuck, slow or fail due to some upstream Github issue. - There's no way to manage the settings of repos in code (e.g. protected branches, status checks, etc) - this is a huge pain point for us as we have to manually set these things up for each repo and branch. - If someone makes a comment on a PR and the author pushes new changes to the PR the conversation doesn't show in the PRs diff, nor do other peoples unresolved comments - but they are all still required to be resolved/closed before a merge can occur - this is not at all obvious to the reviewer or the author. - There's no deployments dashboard to see what is deployed where and what the status of those deployments are. - There's no concept of application health as part of a repo, the code is very disconnected from what is actually deployed. - Notifications are a mess - you can't easily see what notifications you have set up and for what repos. You can't manage them in code. There's so much noise in the notifications that it's hard to see what's important - almost all of them end up getting missed. - There's no way to manage the secrets in code - you have to manually set them up for each repo. - Linting Github Actions workflows is unreliable even using Github/Microsoft's own VSCode and Github Actions plugins. - There is no easy to use way of testing Actions locally or on a branch. - Scheduled workflows only ever run from the default branch. - There's no internal or private Actions marketplace. - Reusing code is an absolute mess, Composite Actions vs Reusable Workflows vs Actions - all slightly different with different edge cases and limitations. (See https://smcleod.net/2022/11/github-not-so-reusable-actions/ https://smcleod.net/2022/11/github-not-so-reusable-actions/) - Standard YAML anchors aren't supported. - There's no way to manage the status checks that must pass across a given set of repos for a team, you have to do them all one by one for each branch that is protected.... - There's no concept of grouping repositories for a project, team or product. - "The console log (which is a critical part of any CI system) is incredibly buggy - often sitting there blank for 10 mins with no output. - Not easy to audit who has made changes or version control settings in the UI. - Retrying a job that failed on an upstream action/workflow after it has been fixed - results in the previous version being used again silently without warning and no option to use latest version. - Custom roles locked down to org admins. - No ability for engineers to update / replace secrets without granting them full blown admin access. - You can't set per-workflow timeouts. - If you're investigating an issue in the console output and the run ends the output is collapsed and you lose what you're looking at and have to find it again. There’s a lot more I can add later.

Could you elaborate a bit on what you don't like about GH Actions? Just curious as I have a lot of experience with Gitlab CI and relatively less with GH Actions.

smcleod 3y ago

Oh gosh where do I even start. Actually, I was recently writing up a list of issues that the teams I work with have with it the other day. I'll share it here however I'll have to post an update to later as it's missing one of my sources. Github is aware of (and somewhat accepts) every one of these items. -There are frequent outages (several times a week, sometimes daily) to Github Actions APIs that result in people having to retry workflows that are stuck, slow or fail due to some upstream Github issue. - There's no way to manage the settings of repos in code (e.g. protected branches, status checks, etc) - this is a huge pain point for us as we have to manually set these things up for each repo and branch. - If someone makes a comment on a PR and the author pushes new changes to the PR the conversation doesn't show in the PRs diff, nor do other peoples unresolved comments - but they are all still required to be resolved/closed before a merge can occur - this is not at all obvious to the reviewer or the author. - There's no deployments dashboard to see what is deployed where and what the status of those deployments are. - There's no concept of application health as part of a repo, the code is very disconnected from what is actually deployed. - Notifications are a mess - you can't easily see what notifications you have set up and for what repos. You can't manage them in code. There's so much noise in the notifications that it's hard to see what's important - almost all of them end up getting missed. - There's no way to manage the secrets in code - you have to manually set them up for each repo. - Linting Github Actions workflows is unreliable even using Github/Microsoft's own VSCode and Github Actions plugins. - There is no easy to use way of testing Actions locally or on a branch. - Scheduled workflows only ever run from the default branch. - There's no internal or private Actions marketplace. - Reusing code is an absolute mess, Composite Actions vs Reusable Workflows vs Actions - all slightly different with different edge cases and limitations. (See https://smcleod.net/2022/11/github-not-so-reusable-actions/ https://smcleod.net/2022/11/github-not-so-reusable-actions/) - Standard YAML anchors aren't supported. - There's no way to manage the status checks that must pass across a given set of repos for a team, you have to do them all one by one for each branch that is protected.... - There's no concept of grouping repositories for a project, team or product. - "The console log (which is a critical part of any CI system) is incredibly buggy - often sitting there blank for 10 mins with no output. - Not easy to audit who has made changes or version control settings in the UI. - Retrying a job that failed on an upstream action/workflow after it has been fixed - results in the previous version being used again silently without warning and no option to use latest version. - Custom roles locked down to org admins. - No ability for engineers to update / replace secrets without granting them full blown admin access. - You can't set per-workflow timeouts. - If you're investigating an issue in the console output and the run ends the output is collapsed and you lose what you're looking at and have to find it again. There’s a lot more I can add later.