4 ms·

In the company I am working we’ve decided to use Github actions for our CI pipelines instead of deploying any “on prem” solution. I’ve worked a lot in the past

In the company I am working we’ve decided to use Github actions for our CI pipelines instead of deploying any “on prem” solution. I’ve worked a lot in the past with Jenkins and Travis and I also played a bit at home with Github actions. Now that I am using it in real world scenarios I have to say that I am a bit disappointed. In my opinion, as soon as you try to do something a bit complex you end up having to implement some nasty hack. Also I found that the Github Actions marketplace is a bit of a sink. You have to spend a good amount of time browsing it for finding something decent that hasn’t been discontinued, or is a pointless fork or at least is actively maintained. This happens even for basic functionalities. I known is a fairly recent platform but I was expecting much more compared to what other services offer.

takeda 5y ago
This is why I like GitLab much more. They implemented a proper CI. I think what GitHub was going for is to create some kind of ecosystem for proprietary 3rd party applications and use that as a revenue. That approach only crippled the whole functionality.
- jaxn 5y ago
  Maybe it's just me, but I refuse to use third party actions in our build and deployment steps. It seems like such an obvious and avoidable attack surface to me, and one where an attached can have root on our production instances and at least some access to all developer machines.
  - ameliaquining 5y ago
    You can solve that by pinning commit hashes, so that nobody can change the code of the actions you use without your consent. You can then use Dependabot to automatically get PRs to update to the latest version of each action when it comes out. You still get the chance to review each PR before it goes in. I wish GitHub would implement a security setting requiring repositories to do this within an organization.
ak217 5y ago
In my experience GHA far outclasses Jenkins and Travis. After GHA released composable actions (https://github.blog/changelog/2021-08-25-github-actions-reduce-duplication-with-action-composition/ https://github.blog/changelog/2021-08-25-github-actions-redu...), there's not much of a comparison to be made. GitLab is more on par, but the docs are less accessible and they don't seem to have a long-term development strategy the way GHA does. As far as the limitations in the blog post, they are real, but most of them are limitations in features that are not available to begin with in Jenkins or Travis.
- cormacrelf 5y ago
  Composable actions… which must be kept in an entirely separate repository. Yes they technically have the feature now, but that is a really poor showing. I won’t be using it for anything because it takes the CI code away from where it’s being run. It’s a niche for people publishing generic actions eg a language specific cache, but most people are not in the business of producing actions for the marketplace. And I don’t like that it’s one repo per action.
  - kylorhall 5y ago
    I use a lot of composite actions in the same repo as well as composite actions across repos. Eg. `workflow1` and `workflow2` both call `composite/action`: .github/workflows/workflow1.yml .github/workflows/workflow2.yml .github/actions/composite/action.yml The only missing bit in that is a bit more support in a composite action: `if` and a few other keywords. Also, it's a bit annoying to access private across across repos.
    - duped 5y ago
      I use zero because of all the showstopping bugs and lack of any introspection or input validation. It saves me a lot of time and money.
    - jaxn 5y ago
      First, thank you. I have been looking for a way to do this and came to the comments to see if there were workarounds to use composite actions without putting them in a separate repo. Which brings me the second comment... this is proof the docs suck. I have looked and looked for any evidence that this exact scenario was possible. There are no examples or documentation of this feature anywhere that I could find.
stevekemp 5y ago
To be honest I've always found the best approach with most of these systems is to checking your magic as shell-scripts inside your repository. Then you're much much more portable. Want to run tests? Run ".ci/tests.sh", want to generate artifacts "make", or ".ci/build.sh". All systems, be they github actions, jenkins, gitlab-runners, and everything else allow you to clone/update your repository and run something from within it. Which keeps things mostly portable. I put together a simple github action a long time ago, but now of course I realize it is overkill: https://github.com/skx/github-action-tester/ https://github.com/skx/github-action-tester/
- rkachowski 5y ago
  I strongly agree. Another benefit with having whatever yaml based CI system simply run your basic shell scripts is that you can actually test your CI runs without a full build cycle.

takeda 5y ago

This is why I like GitLab much more. They implemented a proper CI. I think what GitHub was going for is to create some kind of ecosystem for proprietary 3rd party applications and use that as a revenue. That approach only crippled the whole functionality.

jaxn 5y ago
Maybe it's just me, but I refuse to use third party actions in our build and deployment steps. It seems like such an obvious and avoidable attack surface to me, and one where an attached can have root on our production instances and at least some access to all developer machines.
- ameliaquining 5y ago
  You can solve that by pinning commit hashes, so that nobody can change the code of the actions you use without your consent. You can then use Dependabot to automatically get PRs to update to the latest version of each action when it comes out. You still get the chance to review each PR before it goes in. I wish GitHub would implement a security setting requiring repositories to do this within an organization.

ak217 5y ago

In my experience GHA far outclasses Jenkins and Travis. After GHA released composable actions (https://github.blog/changelog/2021-08-25-github-actions-reduce-duplication-with-action-composition/ https://github.blog/changelog/2021-08-25-github-actions-redu...), there's not much of a comparison to be made. GitLab is more on par, but the docs are less accessible and they don't seem to have a long-term development strategy the way GHA does. As far as the limitations in the blog post, they are real, but most of them are limitations in features that are not available to begin with in Jenkins or Travis.

cormacrelf 5y ago
Composable actions… which must be kept in an entirely separate repository. Yes they technically have the feature now, but that is a really poor showing. I won’t be using it for anything because it takes the CI code away from where it’s being run. It’s a niche for people publishing generic actions eg a language specific cache, but most people are not in the business of producing actions for the marketplace. And I don’t like that it’s one repo per action.
- kylorhall 5y ago
  I use a lot of composite actions in the same repo as well as composite actions across repos. Eg. `workflow1` and `workflow2` both call `composite/action`: .github/workflows/workflow1.yml .github/workflows/workflow2.yml .github/actions/composite/action.yml The only missing bit in that is a bit more support in a composite action: `if` and a few other keywords. Also, it's a bit annoying to access private across across repos.
  - duped 5y ago
    I use zero because of all the showstopping bugs and lack of any introspection or input validation. It saves me a lot of time and money.
  - jaxn 5y ago
    First, thank you. I have been looking for a way to do this and came to the comments to see if there were workarounds to use composite actions without putting them in a separate repo. Which brings me the second comment... this is proof the docs suck. I have looked and looked for any evidence that this exact scenario was possible. There are no examples or documentation of this feature anywhere that I could find.

stevekemp 5y ago

To be honest I've always found the best approach with most of these systems is to checking your magic as shell-scripts inside your repository. Then you're much much more portable. Want to run tests? Run ".ci/tests.sh", want to generate artifacts "make", or ".ci/build.sh". All systems, be they github actions, jenkins, gitlab-runners, and everything else allow you to clone/update your repository and run something from within it. Which keeps things mostly portable. I put together a simple github action a long time ago, but now of course I realize it is overkill: https://github.com/skx/github-action-tester/ https://github.com/skx/github-action-tester/

rkachowski 5y ago
I strongly agree. Another benefit with having whatever yaml based CI system simply run your basic shell scripts is that you can actually test your CI runs without a full build cycle.