Jenkins Pipelines are becoming the standard way to programmatically specify your CI flow.
Please, please don’t be true.
The nicest thing I can say about Jenkins is that it has a fantastic deployment experience. I wish I could say that about literally any other competing hosted CI system— Concourse especially.
That’s how you feel when you use only Jenkins… It’s like this huge echo chamber.
Gitlab (also self hosted) is doing a terrific job at keeping up to date the workflow with other solutions like Travis or Circle. Jenkins is a good solution but has a huge amount of legacy and still an inertia that will keep it from catching up at the same time.
We use Jenkins, but all it does for us is accept webhooks from our central VCS repo on each commit and run make(or other build system) against the new revisions. And to properly yell when things go wrong.
Pushing all this stuff into your CI doesn’t seem to make a lot of sense, as then you get locked in, for little to no gain as I can see.
We treat Jenkins as a distributed task queue, with nice VCS features. Really if Nomad’s task queue or celery or what have you added support for webhooks and a nice way to yell and scream when something went wrong, it would 100% replace Jenkins for us in no time.
At $PREV_JOB we used Jenkinsfiles extensively until some people complained that they couldn’t replicate it on their machine. We were building more and more complex tests scenarios and people wanted to run some parts of them on their laptops before pushing. Some complained that they had to read Groovy code to wrap they head around how tests were launched, but the worse for people were when doing offline remote…
So some people started to write bash scripts to launch stuff (make was another candidate that people found too weird).
Make isn’t that weird, but, it’s not well understood, sadly. But I do agree with your $PREV_JOB, that all of your tests should be runnable , pretty much anywhere. That’s certainly our philosophy.
I’ve been playing with tmuxp using tmux, and running dependencies for testing that way, so that it can all be interactive very easily. Not sure it works out very well for very complex testing scenarios, but it seems to work out for low to medium complexity so far.
Please, please don’t be true.
The nicest thing I can say about Jenkins is that it has a fantastic deployment experience. I wish I could say that about literally any other competing hosted CI system— Concourse especially.
That’s how you feel when you use only Jenkins… It’s like this huge echo chamber.
Gitlab (also self hosted) is doing a terrific job at keeping up to date the workflow with other solutions like Travis or Circle. Jenkins is a good solution but has a huge amount of legacy and still an inertia that will keep it from catching up at the same time.
We use Jenkins, but all it does for us is accept webhooks from our central VCS repo on each commit and run make(or other build system) against the new revisions. And to properly yell when things go wrong.
Pushing all this stuff into your CI doesn’t seem to make a lot of sense, as then you get locked in, for little to no gain as I can see.
We treat Jenkins as a distributed task queue, with nice VCS features. Really if Nomad’s task queue or celery or what have you added support for webhooks and a nice way to yell and scream when something went wrong, it would 100% replace Jenkins for us in no time.
At $PREV_JOB we used
Jenkinsfiles extensively until some people complained that they couldn’t replicate it on their machine. We were building more and more complex tests scenarios and people wanted to run some parts of them on their laptops before pushing. Some complained that they had to read Groovy code to wrap they head around how tests were launched, but the worse for people were when doing offline remote… So some people started to write bash scripts to launch stuff (make was another candidate that people found too weird).Make isn’t that weird, but, it’s not well understood, sadly. But I do agree with your $PREV_JOB, that all of your tests should be runnable , pretty much anywhere. That’s certainly our philosophy.
I’ve been playing with tmuxp using tmux, and running dependencies for testing that way, so that it can all be interactive very easily. Not sure it works out very well for very complex testing scenarios, but it seems to work out for low to medium complexity so far.