4 ms·

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

by jicea 2y ago

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?

imp0cat 2y ago
CI/CD Components: https://docs.gitlab.com/ci/components/ https://docs.gitlab.com/ci/components/ (an evolution of CI/CD templates).
wwarek 2y ago
For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant: https://docs.gitlab.com/ci/yaml/#includeremote https://docs.gitlab.com/ci/yaml/#includeremote
- mqus 2y ago
  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.
  - never_inline 2y ago
    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?
    - mdaniel 2y ago
      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 https://docs.gitlab.com/ci/yaml/#script
HdS84 2y ago
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!
ed_mercer 2y ago
Kaniko + base container images
never_inline 2y ago
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.

by jicea 2y ago

imp0cat 2y ago

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

wwarek 2y ago

For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant: https://docs.gitlab.com/ci/yaml/#includeremote https://docs.gitlab.com/ci/yaml/#includeremote

mqus 2y ago
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.
- never_inline 2y ago
  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?
  - mdaniel 2y ago
    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 https://docs.gitlab.com/ci/yaml/#script

HdS84 2y ago

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!

ed_mercer 2y ago

Kaniko + base container images

never_inline 2y ago

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.