3 ms·

It is clear that build stages should be first class citizens. We based GitLab CI on the awesome work that GoCD and Concourse did in this respect. Our DSL allows

by sytse 11y ago

It is clear that build stages should be first class citizens. We based GitLab CI on the awesome work that GoCD and Concourse did in this respect. Our DSL allows you to assign jobs to stages https://gitlab.com/gitlab-org/gitlab-ce/blob/43e49f52e30199c9724329e71f375874eb76d554/.gitlab-ci.yml#L29 https://gitlab.com/gitlab-org/gitlab-ce/blob/43e49f52e30199c... and jenkins seems to have picked a similar syntax. What is interesting is that Jenkins has a DSL but that this is not part of the repository. This means that it is hard to extend when you introduce new functionality and when you push an old branch it might not work anymore. I think that the model that Travis CI pioneered clearly wins. I'm torn on the plugins. One one hand it is great to be able to plug so much in. But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality. Our idea is: "Because GitLab is open source the enhancements can become part of the codebase instead of being external. This ensures the automated tests for all functionality are continually run, ensuring that plugins always work. It also ensures GitLab can continue to evolve with it’s plugins instead of being bound to a plugin API that is hard to change and that resists refactoring. This ensures we have many years of quality code and great monthly releases ahead of us." https://about.gitlab.com/direction/#vision https://about.gitlab.com/direction/#vision

yamitty11 11y ago
Almost all of what you said here is totally wrong. >What is interesting is that Jenkins has a DSL but that this is not part of the repository. Netflix job dsl plugin, Jenkinsfile pipleline, dotci all of these let you put a .travis.yml like file in your repo. >But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality. Plugins don't have deep access to jenkins internals they use clearly defined "extension points" . I know you are trying to plug gitlab but 'our stuff is better because we don't allow plugins' is not exactly a plus. Jenkins is so popular because it can customized via plugins to wide range of use cases.
- sytse 11y ago
  Thanks for educating me! 1. Cool that there are different plugins that let you check the configuration in a dotfile. 2. I was not aware they used extension points instead of something more intrusive. 3. Obviously I like GitLab and try to promote it. But I post this too to see what others think and to learn. Turns out I had a lot to learn in this case. I still think that some items in Jenkins should be part of the core, such as the pipeline. But I agree that plugins are needed for some cases. For deploys we're thinking about plugins for GitLab CI too in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_4027611 https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_402...
Roritharr 11y ago
I might be an absolute DevOps Newbie, but getting GitLab CI to do a simple "copy to this ssh destination" buildscript seems very complicated. From what I could gather it means that I have to create a specific runner whose login credentials are in its config, which aren't accessible via the WebUi, only as a file on the server where the runner is running and give it an unique tag. Then in my repofile i have to select that specific runner so it then "runs the build" on my deployment target. Hopefully i'm completely wrong about this, but this seems horribly complicated and very inflexible for deployment purposes. Why would I specify my deployment target in my repo? Maybe simple deployment jobs like I'd build them in Jenkins aren't in the scope for GitLab CI?
- sytse 11y ago
  Thanks for the feedback. Deployment with GitLab CI is still harder than it should be and we're working on it in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html http://doc.gitlab.com/ce/ci/variables/README.html
  - Roritharr 11y ago
    Why so complicated? As a first step Please give me a Deployments Page that gives me the option to run simples SH Scripts in the Runner on click, parameterised please. All I need is a nice GUI for my QA people that allows them to deploy(which for our PHP site basically just means copy and DB Import) Branch x on Server y. Jenkins is total Overkill for that but GitLab CI doesnt leave me with enough GUI to skip it either.
    - sytse 11y ago
      I agree that we should have a simple page that shows you an overview, our issue for this is https://gitlab.com/gitlab-org/gitlab-ce/issues/750910 https://gitlab.com/gitlab-org/gitlab-ce/issues/750910

by sytse 11y ago

yamitty11 11y ago

Almost all of what you said here is totally wrong. >What is interesting is that Jenkins has a DSL but that this is not part of the repository. Netflix job dsl plugin, Jenkinsfile pipleline, dotci all of these let you put a .travis.yml like file in your repo. >But the plugins have access deep into the Jenkins internals, preventing a rewrite of core functionality. Plugins don't have deep access to jenkins internals they use clearly defined "extension points" . I know you are trying to plug gitlab but 'our stuff is better because we don't allow plugins' is not exactly a plus. Jenkins is so popular because it can customized via plugins to wide range of use cases.

sytse 11y ago
Thanks for educating me! 1. Cool that there are different plugins that let you check the configuration in a dotfile. 2. I was not aware they used extension points instead of something more intrusive. 3. Obviously I like GitLab and try to promote it. But I post this too to see what others think and to learn. Turns out I had a lot to learn in this case. I still think that some items in Jenkins should be part of the core, such as the pipeline. But I agree that plugins are needed for some cases. For deploys we're thinking about plugins for GitLab CI too in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_4027611 https://gitlab.com/gitlab-org/gitlab-ce/issues/3286#note_402...

Roritharr 11y ago

I might be an absolute DevOps Newbie, but getting GitLab CI to do a simple "copy to this ssh destination" buildscript seems very complicated. From what I could gather it means that I have to create a specific runner whose login credentials are in its config, which aren't accessible via the WebUi, only as a file on the server where the runner is running and give it an unique tag. Then in my repofile i have to select that specific runner so it then "runs the build" on my deployment target. Hopefully i'm completely wrong about this, but this seems horribly complicated and very inflexible for deployment purposes. Why would I specify my deployment target in my repo? Maybe simple deployment jobs like I'd build them in Jenkins aren't in the scope for GitLab CI?

sytse 11y ago
Thanks for the feedback. Deployment with GitLab CI is still harder than it should be and we're working on it in https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 https://gitlab.com/gitlab-org/gitlab-ce/issues/3286 If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html http://doc.gitlab.com/ce/ci/variables/README.html
- Roritharr 11y ago
  Why so complicated? As a first step Please give me a Deployments Page that gives me the option to run simples SH Scripts in the Runner on click, parameterised please. All I need is a nice GUI for my QA people that allows them to deploy(which for our PHP site basically just means copy and DB Import) Branch x on Server y. Jenkins is total Overkill for that but GitLab CI doesnt leave me with enough GUI to skip it either.
  - sytse 11y ago
    I agree that we should have a simple page that shows you an overview, our issue for this is https://gitlab.com/gitlab-org/gitlab-ce/issues/750910 https://gitlab.com/gitlab-org/gitlab-ce/issues/750910