gitlab CI is awesome. too bad it is not a standalone thing.
You can actually use it standalone, for example with GitHub repos: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/githu...
(Disclaimer: GitLab employee here)
Jenkins Is Getting Old
261–270 of 340 posts
Re: Jenkins Is Getting Old
#262I 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…
TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…
I agree. I used TeamCity and liked it. It was like Jenkins, but easier to setup, less messy and just worked for what we needed it. It was worth paying every penny for it.
Re: Jenkins Is Getting Old
#263I 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…
try jenkinsx. It's only named jenkins, but works without it. Supports Kubernetes only though
Re: Jenkins Is Getting Old
#264Earlier quoted context omitted.
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…
I hear you on plugins, and I agree they are problematic. I went back and forth on whether to include this or not TBH.
I'll give you a couple of examples of use cases for plugins:
We have an artifact repo that can store NPM, Python and other artifacts (Nexus if you're interested). I wrote a plugin for TeamCity that can grab artifacts from a build and upload them to the repository. Obviously this can be done in a script, but there are a couple of things that make doing it in a plugin nice:
- You can set it up as a reusable build feature that can be inherited from templates (i.e. all builds of a particular type publish artifacts to Nexus)
- You can get nice UI support. The plugin contributes a tab to the build page that links to the artifacts in Nexus.
- The plugin can tie in to the build cleanup process, and remove the artifacts from the repository when the build is cleaned up. This is useful for snapshot/temporary artifacts that you want to publish so people can test with, but have automatically removed later.
Another example of where plugins have proved useful is influencing build triggering: we have some things that happen in the build server, and then other stuff happens outside of the build server. When all that completes, we then want to kick off another process in the build server (that sounds abstract - think an external deploy process runs, and once the deploy stabilizes you kick off QA jobs). In TeamCity you can write a plugin that keeps builds in the queue until the plugin reports that they are ready to run.
While plugins aren't the first tool I reach for when looking at how to provide reusable functionality in a build server, I have written several plugins for both Jenkins and TeamCity. Overall, I don't think Jenkins/TeamCity's model of having plugins run in-process is a good one, and it leads to most of the problems people have with them (although TeamCity is much better here: Jenkins basically exposes most of its guts to plugins which makes keeping the API stable virtually impossible, while TeamCity has APIs specifically designed for plugins that they've been able to keep stable very effectively) A model where a plugin was just a Docker container that communicated with the build server through some defined APIs, combined with some way for it to attach UI elements to a build that could then call back into the plugin would be much nicer. This seems to be more like what Drone is doing, but haven't played around a lot with that.
I think Gitlab has a strong philosophy of wanting to build out everything that anyone will ever need, all nicely integrated, and that's a great ideal. I think in practice, it's REALLY hard to be all things to all people. People have existing systems and/or weird use cases that it just doesn't make sense to handle all of, and plugins are a useful tool in addressing that.
Re: Jenkins Is Getting Old
#265I 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…
side note: I am confused by your usage of "TFA". I looked it up and it stands for what I thought it does, which has a pejorative connotation. That doesn't seem to be what you meant? https://www.urbandictionary.com/define.php?term=TFA
TFA is in reference to actually Reading TFA or RTFA. Historically, it has very strong roots in Slashdot culture, which was sort of the Hacker News of the late 1990s and all of the 2000s. By using TFA, somewhat indicates you RTFA, as opposed to everyone else who is just speculating on the content of the linked article (didn't RTFA).
Some of us here have been using terms like RTFA and TFA for twenty years, maybe longer.
HTH.
Re: Jenkins Is Getting Old
#266Earlier quoted context omitted.
TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…
Hear hear. And actually, you can get quite far with the free TeamCity license of three build agents and 100 build configs. I’m also fairly sure that Jetbrains would take kindly to license requests from open-source projects and academia.
> I’m also fairly sure that Jetbrains would take kindly to license requests from open-source projects and academia.
Re: Jenkins Is Getting Old
#267drone is like google cloud build and probably and whatever amazon has
Re: Jenkins Is Getting Old
#268Earlier quoted context omitted.
Both work ?
No, the key difference is that Nagios has perfectly viable alternatives (Zabbix admin here and it's not the only one). Jenkins however has no alternatives. Bamboo or whatever it is called now is typical Atlassian crapware. Expensive as fuck, eats more resources than the stuff it builds, and did I mention it is yet another half assed product that got shoddily integrated into the usual Atlassian lineup? Gitlab CI is gr…
GoCD?
Re: Jenkins Is Getting Old
#269Disclaimer: 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…
NO debug overs ssh, why I still use CircleCI.
Re: Jenkins Is Getting Old
#270I 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…
We do have an issue about making it possible to use GitLab Serverless for that use-case easier. Please take a look at https://gitlab.com/gitlab-org/gitlab-ce/issues/61171!