Hacker News Reader

Comment by Octabrain | Hacker News Reader

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.

View on HN

In my experience GHA far outclasses Jenkins and Travis. After GHA released composable actions (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.

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.

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.

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.

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.

Absolutely agree. Docs are either perfect (5%) or…completely obscure (95%). I can't tell the difference between Github Actions and API documentation in places, but I desire functional examples. No clue where I built it up, but I'm comfortable now…lots of trial and error.

For a lot of Github Actions, I actually follow the Github Roadmap through to implementation as the PRs actually have good examples in them… https://github.com/github/roadmap/projects/1

Is it still one action per repo?

Nope, I have a repo consuming 10+ workflows, 3 shared actions, and a handful of private workflows (the way private workflows sucks now though, don't recommend–basically just a git clone into your Github Action).

This is all non-Enterprise, private repos, no clue in GHEC/S.

> GitLab is more on par, but the docs are less accessible and...

Interesting - I find GitLab docs easy to use while I hate GH ones. It takes a long time for me to find the relevant part, even more to determine that this is really all there is, and then some extra to guess which interpretation of the text suits the reality. It has never occured to me that someone might prefer GH docs to GL ones. :)

GHA definitely far outclasses Jenkins and Travis.

However, having also used Buildkite, I'm not sure I could go back to GHA - it's slightly nicer to target, and at least as large a step towards reliability & predictability as Travis -> GHA was.

I use Buildkite all day as part of my job, and I have to say, it's amazing. The company is great to work with, the product is highly flexible for a variety of complex build workflows teams want to implement, and has scaled beautifully for 1000+ concurrent build machines split between on-prem and cloud. No affiliation, just a customer.

> GitLab is more on par

On par? Gitlab CI is lightyears ahead of GHA and shows no sign of stopping: child pipelines, dynamic pipeline generation, very flexible conditionals, composable pipeline definitions, security, merge trains.

GHA is very basic, even simplest thing like individual job restart is not implemented.

My company uses GitLab CI/CD, and I've tried to set up GitHub actions on a personal repo. I've found GitLab's docs to be excellent. GitHub was a bit more confusing, but I got there in the end.

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.

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.

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.

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/

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.

Reply on news.ycombinator.com