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.
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.
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. :)
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.
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.
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
This is all non-Enterprise, private repos, no clue in GHEC/S.
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.
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.