Not at all.
In what concerns Java and .NET projects, Jenkins is just a mature tool that gets the job done.
We have no reason to consider anything else.
Jenkins Is Getting Old
251–260 of 340 posts
Re: Jenkins Is Getting Old
#252Earlier quoted context omitted.
> GUI-oriented Not with pipeline files. I am a total Jenkins noob, but I was able to (relatively) quickly setup a minimal job that automatically pulls config from the relevant GH repo.
Ah yes, pipelines do make a difference in configuring jobs. However, how are you managing your plugins? Your Jenkins configs? Most likely those are manual (however if you've found a way that works well, please share). I've also found that for some functionality, I've had to add Groovy into my pipelines. That said, pipelines has made a HUGE difference. I still want to migrate but this fixes a large pain point.
> (however if you've found a way that works well, please share)
Not extremely well, but I did a small PoC where Jenkins is running in Kubernetes without persistent storage. Plugins are installed on boot with install-plugins.sh (part of Jenkins' Docker image) and configuration is done via Groovy scripts in init.groovy.d (stuff like https://gist.github.com/Buzer/5148372464e2481a797091682fabba...). It's not perfect (e.g. I didn't have time to find out good way to store & import old builds) & it does require some digging around to find how plugins actually do their configuration.
Re: Jenkins Is Getting Old
#253Getting old? It's ancient. Nobody should use Jenkins for new projects. I even started writing my own piece about it on a plane back from a recent vacation.
Re: Jenkins Is Getting Old
#254Jenkins's plugin manager is absolutely terrible. If you're stuck on an older version of Jenkins, you better not click the "refresh" button in the plugin management page, cause otherwise the page is just filled with red warnings saying that the latest version of each plugin is incompatible or has dependencies that are incompatible with your current Jenkins version. There is afaik no way to install the last plugin that…
> There is afaik no way to install the last plugin that was compatible with your version of Jenkins. Probably not directly, but if you know the version, you can download the HPI and install it manually. Jenkin's Docker build also contains install-plugins.sh ( https://github.com/jenkinsci/docker/blob/7b4153f20a61d9c579b... ) that you can use to install specific version of plugin via command line.
Thanks! That script definitely gives some pointers on how to update things.
Re: Jenkins Is Getting Old
#255Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…
I will second this, Gitlab has the best CI I've ever used, and I don't know what it is. The UI is just so clean, it does what I need to and is easy to configure. I put all my projects on Gitlab mostly because of the CI, but also because of the other great features.
GitLab product director for CI/CD here - thanks so much for the feedback, everyone. It's really great to read how much you're getting value out of what we built.
We have an overall CI/CD direction page up at https://about.gitlab.com/direction/cicd which you can drill down into the individual stages plans from. Feedback is always welcome, we love building things in partnership with real users. You can reach me at jason@gitlab.com any time.
Re: Jenkins Is Getting Old
#256Earlier quoted context omitted.
> But in the end CI and CD systems are glorious semi-smart cron runners. I think you’re not appreciating and misrepresenting the complexity and power that comes with these solutions.
You say that, but you do not mention in what way?
You may find our direction page for CI/CD at GitLab interesting if you're looking to learn more about the possibilities involved here. We do all of our planning and roadmapping in public so you read a bit about our overall technical challenges and approach there, and drill down into the stages (CI, packaging, and CD) that make up the capabilities within GitLab, each of which have their own videos and other planning content.
Re: Jenkins Is Getting Old
#257I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…
I’m experimenting right now with how far I can simplify the abstractions, and writing my own thing in rust. Since my use case is integration with gerrit, I poll the updated changes over ssh, and have the regex-based triggers which cause a “job” launches. Job consists of making a database entry and calling a shell script, then updating the entry upon completion. Since job is just a shell script it can kick off other j…
I think these kind of home-grown systems are pretty hard to "sell" to others. I know that I've written a couple, my general approach was to :
* Get triggered by a github (enterprise) webhook.
* Work out the project, and clone it into a temporary directory.
* Launch a named docker container, bind-mounting the temporary directory to "/project" inside the image.
* Once the container exits copy everything from "/output" to the host - those are the generated artifacts.
There's a bit of glue to tie commit-hashes to the appropriate output, and a bit of magic to use `rsync` to allow moving output artifactes to the next container in the pipeline, if multiple steps are run.
But in short I'd probably spend more time explaining the system than an experienced devops person would be creating their own version.
Re: Jenkins Is Getting Old
#258Earlier quoted context omitted.
What can we do better in GitLab?
At my work we use TeamCity for some things and Gitlab CI for others. Things that are good about TeamCity: - Templates Gitlab has something called templates but it's a very different thing. In Gitlab, a template is used to bootstrap a project, but that's it. In TeamCity a template is attached to a project such that if you change the template, changes are applied to all projects that inherit from the template. Each pro…
Thanks for the incredible feedback! CI/CD product director here. A few thoughts:
- Templates
We actually have done a lot here recently, we've improved includes so that they have a lot more flexibility (https://docs.gitlab.com/ee/ci/yaml/#include), and have even refactored our own Auto DevOps implementation to take advantage of this: https://docs.gitlab.com/ee/topics/autodevops/#using-componen.... In this way, you can have included behaviors across your projects that can then be updated in bulk.
- Build results
We are planning on adding testing results over time in our vision for this year, thank you for confirming this is important from your point of view. https://gitlab.com/gitlab-org/gitlab-ee/issues/1020
- Overall view of runner status
We did recently add pipeline info to the operations dashboard (https://docs.gitlab.com/ee/user/operations_dashboard/), which I know isn't exactly what you're looking for here but we are making progress in this direction and recognize the gap.
- Dashboard
The next improvement we're making to that operations dashboard is adding environments. You can see the in-progress issue here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3713
- System wide configs
This can be achieved by using includes to set the variables, which is admittedly a workaround. We do have an open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/3897) to implement instance level variables that would solve this.
- Extensibility
This is an interesting one because Plugins are, at least in my opinion, what makes Jenkins a mess to use in reality and believe me, I've managed plenty of Jenkins instances in my career with lots of "cool" plugins that do something great, at least while they work. It is one of our values that we play well with others, though, so I'd be curious to work with you to understand specifically what you'd like to be able to make GitLab do that can't be done through your .gitlab-ci.yml. Our goal is that you should never be blocked, or really have to jump through hoops, but still not have to be dependent on a lot of your own code or third party plugins.
Re: Jenkins Is Getting Old
#259I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…
Gitlab and Concourse both support windows runners as far as I can see. They also don't require docker, but you might actually want that for most of your jobs. My biggest gripe about gitlab is you can't schedule a job in code, and I suppose it's less then ideal to support 3rd party repos in hosted gitlab, but I don't know why you'd not use it as an SCM. The bigger problem, would be using a group job that triggers a bu…
Hey there, CI/CD product director here. We do allow scheduling/editing/deleting pipelines via code, at least via an API: https://docs.gitlab.com/ee/api/pipeline_schedules.html
Or are you looking more for putting the values in the .gitlab-ci.yml itself? This is something we have thought a bit about, but it gets strange with branches and merges where it's not always clear you're doing what the user wants as the different merges happen.
To your second point, you might be interested in some of the primitives we're looking at building next here: https://about.gitlab.com/direction/cicd/#powerful-integrated.... These, in concert, will help with a lot of more complex workflows.
Re: Jenkins Is Getting Old
#260I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…
GitLab CI is pretty good. I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_. What? I don't even... And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case. Sure as shit be…
GitLab CI/CD product director here - we're working towards making includes more flexible to give you a lot more control. Would love your feedback on the small primitives we're looking at here: https://about.gitlab.com/direction/cicd/#powerful-integrated...
This for us represents our vision so far on where we want to take GitLab CI next and I think addresses where you see gaps with our product today - we see them too.