Hacker News Reader

Comment by jicea | Hacker News Reader

Genuine question: what's the GitLab equivalent of GitHub Actions?

I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

View on HN

CI/CD Components: https://docs.gitlab.com/ci/components/ (an evolution of CI/CD templates).

For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant:

https://docs.gitlab.com/ci/yaml/#includeremote

include:component is usually what you want now, you can version your components (Semver), add a nice readme and it is somewhat integrated in the gitlab UI. Not sure about the other include: ones, but you can also define inputs for component and use them at arbitrary places like template variables.

Since the integration is done statically, it means gitlab can provide you a view of the pipeline script _after_ all components were included, but without actually running it.

We are using this and it is so nice to set up. I have a lot of gripes with other gitlab features (e.g. environments, esp. protected ones and their package registry) but this is one they nailed so far.

Doesn't include:component still require all your shell script to be written inside YAML? or is there a way to move the logic to a, for instance, .sh file and call it from YAML?

I realize this may be splitting hairs, but pedantically there's nothing in GitLab CI's model that requires shell; it is, as best I can tell, 100% docker image based. The most common setup is to use "script:" (or its "before_script:" and "after_script:" friends) but if you wanted to write your pipeline job in brainfuck, you could have your job be { image: example.com/brainfuckery:1, script: "" } and no shell required[1]

1: although TIL that the "script:" field itself is actually required in GLCI https://docs.gitlab.com/ci/yaml/#script

I'd say write a Python CLI (or any language you're comfortable with) which does all the actions (setup, deploy), download it and use it in the CI (or install on the runner images if you control them). That way you can use same workflow (command) in local development and CI.

There is a gitlab CI feature `include`, but you pretty much have to write shell scripts inside YAML, losing on whole developer experience (shellcheck etc..). I would recommend this way only if you can't factor your code into a CLI in proper language.

There is nothing. Oh sure there is include, but that's like most gitlab features: it marks a nice shiny checkbox in some management presentation. But usefulness in the real world is limited. But hey let's do secops oh no AI instead!

Kaniko + base container images

Reply on news.ycombinator.com