>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.
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_402...
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?
If you want to securely store login credentials consider using secure variables http://doc.gitlab.com/ce/ci/variables/README.html
Jenkins is total Overkill for that but GitLab CI doesnt leave me with enough GUI to skip it either.
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