21–30 of 79 posts
I'm surprised people are still using Travis CI. The writing was on the wall the day of the acquisition. I moved all of my builds immediately.
Earlier quoted context omitted.
Definitely look at Jenkins. You can do pretty much whatever you want with it (not always a good thing though of course, use responsibly)
Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)
I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment".
Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job instead of reusing the same environment, slower than Jenkins which does matter for some people.
A particularly dumb case showing this is when something needs to be done on a remote server via ssh - in Jenkins, one has to click "SSH Agent", choose the credential, and you can use "ssh user@host" just fine and do whatever you want. In Gitlab CI, one has to check if ssh is available on the runner image, install it if it isn't present, eval ssh-agent, and only then it works - and all of this needs to be re-done at each run (additionally meaning that your jobs have a dependency on an Internet connection plus the distribution's package servers!). In Jenkins, with a proper tool configuration I can specify something like Maven or NodeJS and Jenkins will automatically install the tool if it is not present and then never again while in Gitlab, again, as it's stateless all will need to be re-done every single build time.
Earlier quoted context omitted.
Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)
Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job inste…
The problem is that each of the magic functions you listed above are separate plugins. They're not part of Jenkins itself. Each plugin may (and often will) push breaking changes and vulnerabilities to your Jenkins instance, if they haven't been outright abandoned by their maintainers. Over time, your builds will steadily accumulate hacks to work around broken plugins, and your Jenkins instance rots.
Earlier quoted context omitted.
Definitely look at Jenkins. You can do pretty much whatever you want with it (not always a good thing though of course, use responsibly)
Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)
Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.
It’s a difficult space. As long as you are looking for “free and someone else maintains it” you are going to be hopping services regularly to stay on something that has VC money to burn for goodwill. If you host it yourself you either have a maintenance headache or a shortage of features. Depends what your time is worth really; I use buildkite with runners on AWS for work, and it doesn’t suck. For personal stuff it’s…
I used Drone CI in the past and liked the focus on Docker containers for everything. It seemed to contain the sprawling monster of bash that seem to occur in enterprise pipelines.
Earlier quoted context omitted.
Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job inste…
That's a good point, there is a vacuum for a good general purpose task automation tool that Jenkins has historically filled. The problem is that each of the magic functions you listed above are separate plugins. They're not part of Jenkins itself. Each plugin may (and often will) push breaking changes and vulnerabilities to your Jenkins instance, if they haven't been outright abandoned by their maintainers. Over time…
Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.
Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.
Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.
It’s a difficult space. As long as you are looking for “free and someone else maintains it” you are going to be hopping services regularly to stay on something that has VC money to burn for goodwill. If you host it yourself you either have a maintenance headache or a shortage of features. Depends what your time is worth really; I use buildkite with runners on AWS for work, and it doesn’t suck. For personal stuff it’s…
Earlier quoted context omitted.
I have had good experiences with Concourse CI, especially for trunk-based development
How do you host concourse? Did you adopt their entire stack? Last time I looked at it, it seemed cool but I had no interest in learning BOSH.
BOSH is not a requirement to host it yourself, and I've never used it.
Probably the easiest way to run it is to use the helm chart[1] and run it on Kubernetes. There are some things to keep in mind, like the workers have their own containerizer that is not Kubernetes-aware. You don't want it competing with Kubernetes for scheduling containers, so it's best to let the worker pods be the the "owner" of their node, and you can use affinities to enforce that.
At one company where we ran it directly on VMs in AWS, I used Ansible to build the CloudFormation stacks for the database (Aurora) and autoscaling groups, and the machines self-configured with Ansible to download and extract the Concourse tarball and start it. I wish I could make that code public but it now lives inside the company where I used it. I guess my point is that running it isn't magic, it's just a program (actually two, web and worker) that you start with some arguments that are pretty well documented[2].
0. https://github.com/cloudboss/ofcourse 1. https://github.com/concourse/concourse-chart 2. https://concourse-ci.org/install.html