3 ms·

Last time I checked (a few weeks ago), Gitlab's CI/CD system is great for most use cases as long as you can describe your pipeline as a list of non-interactive

Last time I checked (a few weeks ago), Gitlab's CI/CD system is great for most use cases as long as you can describe your pipeline as a list of non-interactive tasks -- some of which may be parallelized -- that each can run in a Docker container. For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this. In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this. But if your needs aren't so complex then Gitlab CI is great. It's UX-philosophically similar to Travis and setting it up is super simple, as opposed to Jenkins which is a pain to use.

Already__Taken 9y ago
Can't you put the gitlab runner on whatever you want and set up CI environments to the runner?
- bpicolo 9y ago
  The issue is that the configuration format makes complex jobs difficult to define. It's good for the simple case, but versus e.g. a Jenkinsfile[0] where you get a complete groovy DSL that can interact with it's environment across tasks, pipeline, branch, etc with ease it's rough. Having fine-grained control becomes important. [0] https://jenkins.io/doc/book/pipeline/jenkinsfile/ https://jenkins.io/doc/book/pipeline/jenkinsfile/
  - vorg 9y ago
    > a Jenkinsfile[0] where you get a complete groovy DSL Apache Groovy isn't "complete" as shipped with Jenkins. It's collections API is deliberately crippled so it doesn't work.
zingmars 9y ago
You could achieve something like this with tags - https://docs.gitlab.com/ee/ci/yaml/#tags https://docs.gitlab.com/ee/ci/yaml/#tags. Though you will need to define each machine individually in the CI file.
Snappy 9y ago
> For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this. GitLab CI/CD can certainly run jobs on different OSes, then have a final job consolidate those artifacts and publish to an artifact server. What part can't GitLab do? > In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this. GitLab CI/CD has manual jobs so a pipeline can wait for human sign off before proceeding.

Already__Taken 9y ago

Can't you put the gitlab runner on whatever you want and set up CI environments to the runner?

bpicolo 9y ago
The issue is that the configuration format makes complex jobs difficult to define. It's good for the simple case, but versus e.g. a Jenkinsfile[0] where you get a complete groovy DSL that can interact with it's environment across tasks, pipeline, branch, etc with ease it's rough. Having fine-grained control becomes important. [0] https://jenkins.io/doc/book/pipeline/jenkinsfile/ https://jenkins.io/doc/book/pipeline/jenkinsfile/
- vorg 9y ago
  > a Jenkinsfile[0] where you get a complete groovy DSL Apache Groovy isn't "complete" as shipped with Jenkins. It's collections API is deliberately crippled so it doesn't work.

zingmars 9y ago

You could achieve something like this with tags - https://docs.gitlab.com/ee/ci/yaml/#tags https://docs.gitlab.com/ee/ci/yaml/#tags. Though you will need to define each machine individually in the CI file.

Snappy 9y ago

> For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this. GitLab CI/CD can certainly run jobs on different OSes, then have a final job consolidate those artifacts and publish to an artifact server. What part can't GitLab do? > In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this. GitLab CI/CD has manual jobs so a pipeline can wait for human sign off before proceeding.