10 ms·

Blue Ocean: a new user experience for Jenkins

382 points by Artemis2 10y ago

Roritharr 10y ago
Yes! This! A million times this! I wished for a better Jenkins UI for so long I had given up hope. GitLab CI looked enticing, but after putting so much work into building a workflow that doesn't pollute my repos with environment specific data i'm right back at Jenkins. Thanks for this, this will make it so much clearer to our POs where we stand without spending forever trying to push that info into Jira.
- Artemis2 10y ago
  Have you looked at Concourse? I've only heard good things about it. https://concourse.ci https://concourse.ci
  - fuzzyninja 10y ago
    Concourse is an amazing project, but sadly is very if you are trying to build around a docker type of workflow. This[1] is for us a showstopper atm, so we are sticking to go.cd, although Jenkins seems to be improving a lot lately. [1] https://github.com/concourse/concourse/issues/324 https://github.com/concourse/concourse/issues/324
    - Roritharr 10y ago
      Thats interesting, GitLabs recent focus on the Docker workflow was one thing that irked me, since we won't be using Docker for the foreseeable future and I'm missing quite a few features to replace Jenkins completely. Has concourse good options for manual deployment?
      - fuzzyninja 10y ago
        It surely does. Also, their learning materials are great too. I found to be able to get a basic pipeline in a matter of a couple of hours. If you don't have a docker heavy type of dev workflow, I think it is a great alternative. Totally worth checking it out.
      - jobvandervoort 10y ago
        Note that with GitLab CI, you can having anything run your build. It's just that we typically use Docker as an example and use it ourselves most intensely. GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it runs on anything you can run a Go binary on, which is pretty close to all major platforms. Read more on Runner here: http://docs.gitlab.com/ce/ci/runners/README.html http://docs.gitlab.com/ce/ci/runners/README.html And congrats to the Jenkins team! This looks amazing. A majority of our customers uses Jenkins. I'm sure they'll be excited to update.
        gearlles 10y ago
        My problem with Gitlab CI is that it's not as smart as Jenkins for Java projects. Jenkins beautifully handles maven multi-module projects and knows how to install the dependencies. All other CI-systems are available in Gitlab CE, but Jenkins integration is only available on Gitlab EE. That's the only reason my team doesn't use Gitlab as code repo.
      - jacques_chester 10y ago
        You don't have to "use docker" to use Concourse. It runs docker images under the hood. It only becomes relevant when you define which container image to use to run things. After a little while you'll realise you want something a bit different, at which point the docker-image resource that's supported by the Concourse team makes it embarrassingly easy. You just tell Concourse "yo, push to this image" and it does the rest.
  - Roritharr 10y ago
    Not yet, looks interesting though. But now i've got to checkout GoCD and Concourse instead of getting BlueOcean Running after updating Jenkins... all those choices, a blessing and a curse.
- i386 10y ago
  So glad you are excited! Let me know if you've got any feedback or suggestions.
  - Roritharr 10y ago
    Setting up a test instance right now. :)
    - i386 10y ago
      Would love to hear how you are going with it. Perhaps post your thoughts to the user mailing list? https://jenkins.io/content/mailing-lists/ https://jenkins.io/content/mailing-lists/
- sytse 10y ago
  What do you mean with polluting repos with environments specific data? I hope we address your concern in GitLab CI with environments in GitLab 8.9 due June 22 and environment specific environmental variables in GitLab 8.10 due July 22.
karterk 10y ago
I have worked with many open and proprietary CI tools, and find GoCD to be the best in this space right now. It supports both Continuous Integration and Continuous Delivery. They also made it open source last year: https://www.go.cd/ https://www.go.cd/
- dominotw 10y ago
  do you work for thoughtworks?. Every single post about Jenkins ends up with bunch of people from thoughtworks blindly shilling for their ci software. Do you guys mind not doing that please?
  - jacques_chester 10y ago
    Those of us at Pivotal come and rave about Concourse. So I guess it evens out. GoCD was an important step forward conceptually. It's just an actually awful piece of software to try and use.
  - orpheansodality 10y ago
    This seemed like quite the assumption, so I did some light digging. This person definitely does not work for ThoughtWorks.
    - dominotw 10y ago
      I observed this pattern from previous jenkins posts. But I did some digging after your comment and there it is http://www.indix.com/blog/life-at-indix/employee-spotlight-kishore-nallan/ http://www.indix.com/blog/life-at-indix/employee-spotlight-k... What did you do before Indix? I was working at ThoughtWorks as a software engineer.
      - karterk 10y ago
        Well done I guess :) I worked briefly at ThoughtWorks, but definitely don't have any vested interests. ThoughtWorks produces not-so-great products too (like Mingle), but Go CI is definitely a great piece of software. And, I say that as someone who also has used Jenkins a lot. Also, it's now completely open source. I'm not even trying to advocate an enterprise product.
luka-birsa 10y ago
We're running both GitlabCI and Jenkins (different teams) inhouse. Gitlab really upped their Game with the integrated Docker repo (we've adopted Docker heavily) but it is lacking the plugin ecosystem of Jenkins. Jenkins on the other hand just feels dated. The new ui is very welcome. Looks like we're going to keep the dual approach for a while until things crystallize further.
- i386 10y ago
  Anything you think we could do to shorten the gap between the two?
  - luka-birsa 10y ago
    Integrate into Gitlab, so we do not require a secondary Service. :)
- sytse 10y ago
  What Jenkins plugins do you need that are not available as features in GitLab?
rcarmo 10y ago
This is excellent news. Jenkins is often the hardest thing for people to get to grips with in a CI pipeline solely because of the UI/UX, and I, for one, welcome our redesigned build butlers... :)
benbristow 10y ago
Looks much better! I've never used Jenkins for my own projects but I've used it before when Minecraft's 'bukkit' framework used to use it and it's a horrible piece of web software to navigate.
- phit_ 10y ago
  It's still being used by the successor of bukkit ;) https://hub.spigotmc.org/jenkins/view/All/ https://hub.spigotmc.org/jenkins/view/All/
truebosko 10y ago
I love Jenkins, and it's incredibly important for our teams. The redesign offering much stronger focus on the pipeline is key in helping us (and perhaps many) teams move past the "Continuous build tool" phase and into the "Continuous integration/deployment" tool we would love!
- i386 10y ago
  Only possible due to the team working on Jenkins Pipeline and the plugin developers who've started adopting it in their plugins. Happy to hear you love Jenkins too :)
jupp0r 10y ago
I just wish they would have used this change to get rid of the weather icons ...
- i386 10y ago
  Interesting - why do you think they should be removed? I purposely kept them because they felt a very positive part of the Jenkins personality.
  - jupp0r 10y ago
    Just a matter of personal taste, they don't deliver the fast visual clues to me that simple red and green elements do in other CI systems like bamboo. From a distance, they look quite similar and that fails to give me a quick overview. From my experience, they are a very polarizing piece of UI design :)
    - Ygg2 10y ago
      They seem to have advantage for color blind people, no? It's easier to disambiguate shapes than colors.
      - calvins 10y ago
        It's easier to disambiguate shapes and colors than just shapes or just colors -- something like a checkmark of one color, and an X of a different color.
        i386 10y ago
        FWIW We've got colored indicators that have appropriate iconography for these kinds of users.
    - JorgeGT 10y ago
      I agree with you, and it's very easy to test. Print 15 mixed weather icons on one sheet of paper and 15 red/green/orange circles in another. Show them to test subjects for 1-2 seconds, and ask them to assess the situation. Now repeat the test, but showing the sheets from two meters away. Our brain is really good at color cues, and especially red = danger is deeply wired into us!
smartbit 10y ago
I wonder how fast cloud bees will upgrade their new exam [0] based on version 1.625.2 of the Jenkins core? The exams where only available since last month and already quite outdated since version 2.0 was introduced [1]. What alternatives to exams exist to asses someone's knowledge and experience in using, managing & maintaining an application? [0] https://www.cloudbees.com/sites/default/files/cje_study_guide.pdf https://www.cloudbees.com/sites/default/files/cje_study_guid... [1] https://news.ycombinator.com/item?id=11362058 https://news.ycombinator.com/item?id=11362058 & https://news.ycombinator.com/item?id=11574487 https://news.ycombinator.com/item?id=11574487
- issc29 10y ago
  actually the Pipeline plugin was listed in the study guide, which was probably the biggest change of 2.0 anyways (where it is now by default installed as a Recommended Plugin) :-)
franblas 10y ago
Very good news. I love Jenkins but the interface is not very friendly and even with some themes templates like this one https://github.com/jenkins-contrib-themes/jenkins-material-theme https://github.com/jenkins-contrib-themes/jenkins-material-t... it's still hard to navigate and get right informations. Definitively yes for this integration!
- i386 10y ago
  Thanks for the kind words :)
zxcvcxz 10y ago
CLASSIC HN (2 Months ago) https://news.ycombinator.com/item?id=11362058 https://news.ycombinator.com/item?id=11362058 >Jenkins 2.0 Beta Almost every top level comment is very negative. I just think the discussion now vs the discussion then is worth noting. People seem much more positive about jenkins just in the last few weeks. Recently since it was integrated into Azure those negative comments have started to get downvoted, in favor of positive ones. https://news.ycombinator.com/item?id=11737374 https://news.ycombinator.com/item?id=11737374 Very interesting. I figure this is just the more "corporate culture" here on HN.
i386 10y ago
My team and I designed Blue Ocean. We are really excited to get your feedback and suggestions. Ask me anything :)
- badlogic 10y ago
  First, let me say this looks amazing. Thanks for your work! My biggest issue with Jenkins so far has been configuring complex jobs. The single configuration page just gets unwiedly fast, and important settings are often hidden by default. Is there any work being done to make this easier as well?
  - i386 10y ago
    Wow thanks for the complement - I'm chuffed! There's a trend to move job configuration to a Jenkinsfile that's stored in a Git repository using Jenkins Pipeline. What used to be several jobs is now one Pipeline job config defined using this DSL https://jenkins.io/solutions/pipeline/ https://jenkins.io/solutions/pipeline/ Today the pipeline visualization only works with this way of making jobs. Now we realize this isn't for everyone and we are thinking about how to let users create Jenkins Pipelines through the UI without having to know the DSL (just like freestyle). We are also looking at making Pipeline easier for beginners too.
    - agentgt 10y ago
      It probably doesn't need reiterating but not having Travis like config is my biggest issue with Jenkins as well. While Pipeline looks awesome for sophisticated entities that have complex workflow it seems overly powerful for most I think that just have a lot of projects and configuration drift. Pipeline unlike Travis Yaml is also not a declarative language. One of the advantages of using a declarative markup language that respects comments and spaces (cough XML) would be for the Web UI editor to intelligently edit the configuration files while respecting order, formatting and comments (right now I believe Jenkins XStreams so its just naive serialization).
      - christop 10y ago
joneholland 10y ago
I've yet to find a build system that is better than TeamCity.
- ajmurmann 10y ago
  It's interesting how little attention it gets. I believe it's mainly because it costs money which is a silly reason. I've worked with many clients who spent hundreds of thousands of dollars on getting software built. Yet only one client ever went fire Team City. No one else even considered it because it costs a minute amount of money. To me the option of selecting a snippet of code in the editor and running it on Ci is worth a lot.
jacques_chester 10y ago
This is a fantastic upgrade to Jenkins, well done. Sincerely, A Concourse Fan.
- i386 10y ago
  Thanks jacques! Keen to know if there are any gaps between concourse and Jenkins that we could be doing a better job of filling. Edit: oh right you work for Pivitol ;)
  - jacques_chester 10y ago
    I do, first in Labs and now in Cloud Foundry. On the Labs side lots of our clients are still committed to Jenkins, so improvements like these are very welcome.
hjgilmore 10y ago
Looks really great! Much more modern and visually clean.
- i386 10y ago
  Thank you!
serbrech 10y ago
I like the concept or pipeline, and I like that the definition can be checked in with the code, but : * I don't like to couple the builds to a product * Can I run the build locally? if something goes, how to I know if it's a bug in the pipeline script, the build server environment, or my code. I want reproducible builds.
- i386 10y ago
  Many teams opt to keep most of the logic of their process inside shell scripts or build tools (like Maven or Make). I'm not sure if there is any standard way of defining a Pipeline in the way I think you are asking that is tool agnostic. Building locally is a good one and thats something I am thinking about in the long term.
- tomfennelly 10y ago
  The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong. Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.
  - jacques_chester 10y ago
    I can confirm that this is the pattern that folks on Concourse have moved towards as well. When the CI system has high-level primitives for showing and organising build graphs, it makes sense to surface those instead of burying them inside a relatively opaque build tool.
stuaxo 10y ago
About time! This is great.

382 points by Artemis2 10y ago

Yes! This! A million times this! I wished for a better Jenkins UI for so long I had given up hope. GitLab CI looked enticing, but after putting so much work into building a workflow that doesn't pollute my repos with environment specific data i'm right back at Jenkins. Thanks for this, this will make it so much clearer to our POs where we stand without spending forever trying to push that info into Jira.

Artemis2 10y ago
Have you looked at Concourse? I've only heard good things about it. https://concourse.ci https://concourse.ci
- fuzzyninja 10y ago
  Concourse is an amazing project, but sadly is very if you are trying to build around a docker type of workflow. This[1] is for us a showstopper atm, so we are sticking to go.cd, although Jenkins seems to be improving a lot lately. [1] https://github.com/concourse/concourse/issues/324 https://github.com/concourse/concourse/issues/324
  - Roritharr 10y ago
    Thats interesting, GitLabs recent focus on the Docker workflow was one thing that irked me, since we won't be using Docker for the foreseeable future and I'm missing quite a few features to replace Jenkins completely. Has concourse good options for manual deployment?
    - fuzzyninja 10y ago
      It surely does. Also, their learning materials are great too. I found to be able to get a basic pipeline in a matter of a couple of hours. If you don't have a docker heavy type of dev workflow, I think it is a great alternative. Totally worth checking it out.
    - jobvandervoort 10y ago
      Note that with GitLab CI, you can having anything run your build. It's just that we typically use Docker as an example and use it ourselves most intensely. GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it runs on anything you can run a Go binary on, which is pretty close to all major platforms. Read more on Runner here: http://docs.gitlab.com/ce/ci/runners/README.html http://docs.gitlab.com/ce/ci/runners/README.html And congrats to the Jenkins team! This looks amazing. A majority of our customers uses Jenkins. I'm sure they'll be excited to update.
      - gearlles 10y ago
        My problem with Gitlab CI is that it's not as smart as Jenkins for Java projects. Jenkins beautifully handles maven multi-module projects and knows how to install the dependencies. All other CI-systems are available in Gitlab CE, but Jenkins integration is only available on Gitlab EE. That's the only reason my team doesn't use Gitlab as code repo.
    - jacques_chester 10y ago
      You don't have to "use docker" to use Concourse. It runs docker images under the hood. It only becomes relevant when you define which container image to use to run things. After a little while you'll realise you want something a bit different, at which point the docker-image resource that's supported by the Concourse team makes it embarrassingly easy. You just tell Concourse "yo, push to this image" and it does the rest.
- Roritharr 10y ago
  Not yet, looks interesting though. But now i've got to checkout GoCD and Concourse instead of getting BlueOcean Running after updating Jenkins... all those choices, a blessing and a curse.
i386 10y ago
So glad you are excited! Let me know if you've got any feedback or suggestions.
- Roritharr 10y ago
  Setting up a test instance right now. :)
  - i386 10y ago
    Would love to hear how you are going with it. Perhaps post your thoughts to the user mailing list? https://jenkins.io/content/mailing-lists/ https://jenkins.io/content/mailing-lists/
sytse 10y ago
What do you mean with polluting repos with environments specific data? I hope we address your concern in GitLab CI with environments in GitLab 8.9 due June 22 and environment specific environmental variables in GitLab 8.10 due July 22.

karterk 10y ago

I have worked with many open and proprietary CI tools, and find GoCD to be the best in this space right now. It supports both Continuous Integration and Continuous Delivery. They also made it open source last year: https://www.go.cd/ https://www.go.cd/

dominotw 10y ago
do you work for thoughtworks?. Every single post about Jenkins ends up with bunch of people from thoughtworks blindly shilling for their ci software. Do you guys mind not doing that please?
- jacques_chester 10y ago
  Those of us at Pivotal come and rave about Concourse. So I guess it evens out. GoCD was an important step forward conceptually. It's just an actually awful piece of software to try and use.
- orpheansodality 10y ago
  This seemed like quite the assumption, so I did some light digging. This person definitely does not work for ThoughtWorks.
  - dominotw 10y ago
    I observed this pattern from previous jenkins posts. But I did some digging after your comment and there it is http://www.indix.com/blog/life-at-indix/employee-spotlight-kishore-nallan/ http://www.indix.com/blog/life-at-indix/employee-spotlight-k... What did you do before Indix? I was working at ThoughtWorks as a software engineer.
    - karterk 10y ago
      Well done I guess :) I worked briefly at ThoughtWorks, but definitely don't have any vested interests. ThoughtWorks produces not-so-great products too (like Mingle), but Go CI is definitely a great piece of software. And, I say that as someone who also has used Jenkins a lot. Also, it's now completely open source. I'm not even trying to advocate an enterprise product.

luka-birsa 10y ago

We're running both GitlabCI and Jenkins (different teams) inhouse. Gitlab really upped their Game with the integrated Docker repo (we've adopted Docker heavily) but it is lacking the plugin ecosystem of Jenkins. Jenkins on the other hand just feels dated. The new ui is very welcome. Looks like we're going to keep the dual approach for a while until things crystallize further.

i386 10y ago
Anything you think we could do to shorten the gap between the two?
- luka-birsa 10y ago
  Integrate into Gitlab, so we do not require a secondary Service. :)
sytse 10y ago
What Jenkins plugins do you need that are not available as features in GitLab?

rcarmo 10y ago

This is excellent news. Jenkins is often the hardest thing for people to get to grips with in a CI pipeline solely because of the UI/UX, and I, for one, welcome our redesigned build butlers... :)

benbristow 10y ago

Looks much better! I've never used Jenkins for my own projects but I've used it before when Minecraft's 'bukkit' framework used to use it and it's a horrible piece of web software to navigate.

phit_ 10y ago
It's still being used by the successor of bukkit ;) https://hub.spigotmc.org/jenkins/view/All/ https://hub.spigotmc.org/jenkins/view/All/

truebosko 10y ago

I love Jenkins, and it's incredibly important for our teams. The redesign offering much stronger focus on the pipeline is key in helping us (and perhaps many) teams move past the "Continuous build tool" phase and into the "Continuous integration/deployment" tool we would love!

i386 10y ago
Only possible due to the team working on Jenkins Pipeline and the plugin developers who've started adopting it in their plugins. Happy to hear you love Jenkins too :)

jupp0r 10y ago

I just wish they would have used this change to get rid of the weather icons ...

i386 10y ago
Interesting - why do you think they should be removed? I purposely kept them because they felt a very positive part of the Jenkins personality.
- jupp0r 10y ago
  Just a matter of personal taste, they don't deliver the fast visual clues to me that simple red and green elements do in other CI systems like bamboo. From a distance, they look quite similar and that fails to give me a quick overview. From my experience, they are a very polarizing piece of UI design :)
  - Ygg2 10y ago
    They seem to have advantage for color blind people, no? It's easier to disambiguate shapes than colors.
    - calvins 10y ago
      It's easier to disambiguate shapes and colors than just shapes or just colors -- something like a checkmark of one color, and an X of a different color.
      - i386 10y ago
        FWIW We've got colored indicators that have appropriate iconography for these kinds of users.
  - JorgeGT 10y ago
    I agree with you, and it's very easy to test. Print 15 mixed weather icons on one sheet of paper and 15 red/green/orange circles in another. Show them to test subjects for 1-2 seconds, and ask them to assess the situation. Now repeat the test, but showing the sheets from two meters away. Our brain is really good at color cues, and especially red = danger is deeply wired into us!

smartbit 10y ago

I wonder how fast cloud bees will upgrade their new exam [0] based on version 1.625.2 of the Jenkins core? The exams where only available since last month and already quite outdated since version 2.0 was introduced [1]. What alternatives to exams exist to asses someone's knowledge and experience in using, managing & maintaining an application? [0] https://www.cloudbees.com/sites/default/files/cje_study_guide.pdf https://www.cloudbees.com/sites/default/files/cje_study_guid... [1] https://news.ycombinator.com/item?id=11362058 https://news.ycombinator.com/item?id=11362058 & https://news.ycombinator.com/item?id=11574487 https://news.ycombinator.com/item?id=11574487

issc29 10y ago
actually the Pipeline plugin was listed in the study guide, which was probably the biggest change of 2.0 anyways (where it is now by default installed as a Recommended Plugin) :-)

franblas 10y ago

Very good news. I love Jenkins but the interface is not very friendly and even with some themes templates like this one https://github.com/jenkins-contrib-themes/jenkins-material-theme https://github.com/jenkins-contrib-themes/jenkins-material-t... it's still hard to navigate and get right informations. Definitively yes for this integration!

i386 10y ago
Thanks for the kind words :)

zxcvcxz 10y ago

CLASSIC HN (2 Months ago) https://news.ycombinator.com/item?id=11362058 https://news.ycombinator.com/item?id=11362058 >Jenkins 2.0 Beta Almost every top level comment is very negative. I just think the discussion now vs the discussion then is worth noting. People seem much more positive about jenkins just in the last few weeks. Recently since it was integrated into Azure those negative comments have started to get downvoted, in favor of positive ones. https://news.ycombinator.com/item?id=11737374 https://news.ycombinator.com/item?id=11737374 Very interesting. I figure this is just the more "corporate culture" here on HN.

i386 10y ago

My team and I designed Blue Ocean. We are really excited to get your feedback and suggestions. Ask me anything :)

badlogic 10y ago
First, let me say this looks amazing. Thanks for your work! My biggest issue with Jenkins so far has been configuring complex jobs. The single configuration page just gets unwiedly fast, and important settings are often hidden by default. Is there any work being done to make this easier as well?
- i386 10y ago
  Wow thanks for the complement - I'm chuffed! There's a trend to move job configuration to a Jenkinsfile that's stored in a Git repository using Jenkins Pipeline. What used to be several jobs is now one Pipeline job config defined using this DSL https://jenkins.io/solutions/pipeline/ https://jenkins.io/solutions/pipeline/ Today the pipeline visualization only works with this way of making jobs. Now we realize this isn't for everyone and we are thinking about how to let users create Jenkins Pipelines through the UI without having to know the DSL (just like freestyle). We are also looking at making Pipeline easier for beginners too.
  - agentgt 10y ago
    It probably doesn't need reiterating but not having Travis like config is my biggest issue with Jenkins as well. While Pipeline looks awesome for sophisticated entities that have complex workflow it seems overly powerful for most I think that just have a lot of projects and configuration drift. Pipeline unlike Travis Yaml is also not a declarative language. One of the advantages of using a declarative markup language that respects comments and spaces (cough XML) would be for the Web UI editor to intelligently edit the configuration files while respecting order, formatting and comments (right now I believe Jenkins XStreams so its just naive serialization).
    - christop 10y ago

joneholland 10y ago

I've yet to find a build system that is better than TeamCity.

ajmurmann 10y ago
It's interesting how little attention it gets. I believe it's mainly because it costs money which is a silly reason. I've worked with many clients who spent hundreds of thousands of dollars on getting software built. Yet only one client ever went fire Team City. No one else even considered it because it costs a minute amount of money. To me the option of selecting a snippet of code in the editor and running it on Ci is worth a lot.

jacques_chester 10y ago

This is a fantastic upgrade to Jenkins, well done. Sincerely, A Concourse Fan.

i386 10y ago
Thanks jacques! Keen to know if there are any gaps between concourse and Jenkins that we could be doing a better job of filling. Edit: oh right you work for Pivitol ;)
- jacques_chester 10y ago
  I do, first in Labs and now in Cloud Foundry. On the Labs side lots of our clients are still committed to Jenkins, so improvements like these are very welcome.

hjgilmore 10y ago

Looks really great! Much more modern and visually clean.

i386 10y ago
Thank you!

serbrech 10y ago

I like the concept or pipeline, and I like that the definition can be checked in with the code, but : * I don't like to couple the builds to a product * Can I run the build locally? if something goes, how to I know if it's a bug in the pipeline script, the build server environment, or my code. I want reproducible builds.

i386 10y ago
Many teams opt to keep most of the logic of their process inside shell scripts or build tools (like Maven or Make). I'm not sure if there is any standard way of defining a Pipeline in the way I think you are asking that is tool agnostic. Building locally is a good one and thats something I am thinking about in the long term.
tomfennelly 10y ago
The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong. Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.
- jacques_chester 10y ago
  I can confirm that this is the pattern that folks on Concourse have moved towards as well. When the CI system has high-level primitives for showing and organising build graphs, it makes sense to surface those instead of burying them inside a relatively opaque build tool.

stuaxo 10y ago

About time! This is great.