[Blue Ocean] A new user experience project for Jenkins

[James Dumay]

Hi Jenkins users,

Today I am happy to announce the open sourcing of a new user experience for Jenkins called Blue Ocean.

We are looking to build an excellent experience around Pipeline and Freestyle jobs with a focus on developer experience - how you as a developer build better automation, easily diagnose failures, integrate with tools like Github, Bitbucket or Slack and onboard new team members. These are goals of the uttermost importance to this project.

We realise that we can’t do this alone and it will take more than just Jenkins developers to make this effort successful. We need to hear from the Jenkins user community about their thoughts on the project, where it is heading and how we can help you hone your craft and build better software using Jenkins.

Today we’ve made the source code available on Github, written a blog post and created a video explaining the project in more detail. We will be posting more updates to both the blog and mailing lists when there are more updates to share.

If you have any questions or comments please reply to this post and I’ll be more than happy to answer any questions you may have :)

Thanks,

James

[Lars.M...@edict.de]

Seems to be cool stuff. I tried to install the plugin on our Jenkins as where switching to pipeline building at the moment but couldnt find the plugin in the update center.
But the readme of the describes it more as a standalone installation:
Running Blue Ocean
$ cd blueocean-plugin
$ mvn hpi:run
Then open http://localhost:8080/jenkins/blue to start using Blue Ocean.

Thanks,

James

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8da10afa-bbe8-4d6f-812c-b9a286f64569%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dirk Heinrichs]

Am 27.05.2016 um 00:21 schrieb James Dumay:

Today we’ve made the source code available on Github, written a blog post and created a video explaining the project in more detail.

Unfortunately, the blog post is not completely readable, because the schedule on the right side overlapps the text.

Bye...

    Dirk

--

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

[nicolas de loof]

source code actually has been moved to https://github.com/jenkinsci/blueocean

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/53fe65f9-348b-f110-c9f6-578d6eaa18be%40recommind.com.

[James Dumay]

Fixing the website right now. Sorry about that :(

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Y9uzX4jVCsw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CANMVJzm_SMmWeS93A7U9x19Z%2BG_4oEzaV_-nMO%3D6Y4pb3v2VGw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

James Dumay

Product Manager

CloudBees, Inc.

Skype: ap_myskype Twitter: i386

[Craig Rodrigues]

Hi,

The new Jenkins UI looks nice, and will be a big improvement over the existing UI.

The original selling point of Jenkins was that even with the simplistic forms-based UI,

someone could fill out a relatively simple form, and have a continuous integration pipeline.

I have met people who were general devops and scripting people, and could use Jenkins quite nicely.

While I understand the motivation for Pipeline (previously known as Workflow), I can't say I'm very happy with the results.

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.
• Documentation for Pipeline scripts isn't that great (although it has definitely been improving).  In all honesty, I cannot point a junior scripting person to write a good Pipeline script for developing a build Pipeline.
  
• The durable task plugin which invokes shell commands on Unix, and batch jobs on Windows goes through an elaborate method for invoking shell commands.  It is very, very difficult to grab the exit status of commands, stderr, stdout, etc.  For a while, these wrappers would do things like not detect when a command had terminated, etc. (Looks like this has been fixed now)
• It is very hard to figure out how to cancel a running Pipeline job.  The UI link to "Click here to cancel" a Pipeline job is hidden in the build output, and often doesn't work.

I understand that Jenkins is going through a big transition period.  Hopefully at the end of the road, things will be much better.

However, at this point in time, I would say that in many ways, the current direction is worse than the old way of doing things with the old Jenkins UI.

The old way has problems, but it was easy to figure out, and didn't have a lot of these intermediate layers that try to abstract things out,

but make things harder to figure out what is going on.

--

Craig

[James Dumay]

Tyler was nice enough to get out of bed to deploy the change to jenkins.io - should now be readable on any device.

I owe Tyler a case of beer now...

[Tom Fennelly]

On Friday, May 27, 2016 at 7:59:41 AM UTC+1, Craig Rodrigues wrote:

Hi,

The new Jenkins UI looks nice, and will be a big improvement over the existing UI.

The original selling point of Jenkins was that even with the simplistic forms-based UI,

someone could fill out a relatively simple form, and have a continuous integration pipeline.

I have met people who were general devops and scripting people, and could use Jenkins quite nicely.

While I understand the motivation for Pipeline (previously known as Workflow), I can't say I'm very happy with the results.

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.
• Documentation for Pipeline scripts isn't that great (although it has definitely been improving).  In all honesty, I cannot point a junior scripting person to write a good Pipeline script for developing a build Pipeline.
  
• The durable task plugin which invokes shell commands on Unix, and batch jobs on Windows goes through an elaborate method for invoking shell commands.  It is very, very difficult to grab the exit status of commands, stderr, stdout, etc.  For a while, these wrappers would do things like not detect when a command had terminated, etc. (Looks like this has been fixed now)
• It is very hard to figure out how to cancel a running Pipeline job.  The UI link to "Click here to cancel" a Pipeline job is hidden in the build output, and often doesn't work.

I understand that Jenkins is going through a big transition period.  Hopefully at the end of the road, things will be much better.

However, at this point in time, I would say that in many ways, the current direction is worse than the old way of doing things with the old Jenkins UI.

The old way has problems, but it was easy to figure out, and didn't have a lot of these intermediate layers that try to abstract things out,

but make things harder to figure out what is going on.

--

Craig

Hi Craig.

I hear what you are saying. I think your comments are fair and are things that we need to address.

I think you'll agree that the lower level details relating to how specific plugins work (durable task etc) is a "general" Jenkins/pipeline problem that needs to be addressed i.e. is not really specific to the Blue Ocean (BO) project.

As for the usability issues wrt actually "using" Jenkins pipeline (creating flow/execution scripts etc), they are most definitely issues that are very relevant to the BO project. Some prototyping work was done in this area a while back (and maybe there are other efforts too) and it seems natural that the plan would be to pick one of these up again in some form and build it into BO, making pipeline "author" more of a visual (drag & drop .. fill out a form) kind of process.

[James Dumay]

Ill prepare a post for the mailing list tomorrow showing off some of our ideas for a visual editor - we want to make it just as easy to use Pipeline jobs as it is to use FreeStyle today. I agree, things are not where they are at but we are working hard on it. Ill ask someone to share some ideas that we have around making Pipeline easier to author and understand when in a Jenkinsfile too.

[Michael Neale]

Hi Craig - well for pipeline specifically, if you jump on the dev list andrew is trying to flag down some interest in a declarative script: https://groups.google.com/forum/#!topic/jenkinsci-dev/Vsvq6UkIRAQ which should be easy for most. 

As for a form based thing, I expect that to be around in any new world (freestyle or simplified pipeline, same result, type in a script). 

If you have any thought on the plumber thing (which keeps people away from being groovy experts) please lets talk on the dev list. 

[Dirk Heinrichs]

Am 27.05.2016 um 09:44 schrieb James Dumay:

Tyler was nice enough to get out of bed to deploy the change to jenkins.io - should now be readable on any device.

Yes, looks much better now. Thanks a lot for having it fixed so fast!!!

[Lars.M...@edict.de]

As the old world will disappear the easy way to create build jobs is still available for the non-experts, but for me the new world of pipeline-as-code, its great because now we can handle the jenkins logic the same well as the rest as our code.
Yes pipeline scripts are code but thats fine because we're developers.

So for me the merge of old and new world is great for all.

Von:        James Dumay <jdu...@cloudbees.com>
An:        Jenkins Users <jenkins...@googlegroups.com>,
Kopie:        rod...@freebsd.org
Datum:        27.05.2016 09:49
Betreff:        Re: [Blue Ocean] A new user experience project for Jenkins
Gesendet von:        jenkins...@googlegroups.com

---

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to

jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e8e9ef9f-5636-4608-a27c-66af41aa0d65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Neale]

Well I hope the old doesn't go away! I don't think that is the intention. Pipeline-as-code is just a tidy starting point. There are a lot of freestyle jobs that people get a lot of value out of, and will for a long time. That non code type of working needs to be supported too, as you say - a merge of things. 

On Friday, May 27, 2016 at 5:54:46 PM UTC+10, Lars.M...@edict.de wrote:

As the old world will disappear the easy way to create build jobs is still available for the non-experts, but for me the new world of pipeline-as-code, its great because now we can handle the jenkins logic the same well as the rest as our code.
Yes pipeline scripts are code but thats fine because we're developers.

So for me the merge of old and new world is great for all.

[James Dumay]

My pleasure :)

[Lars.M...@edict.de]

Sorry I meant will NOT disappear

Von:        Michael Neale <mne...@cloudbees.com>
An:        Jenkins Users <jenkins...@googlegroups.com>,
Kopie:        Lars.M...@edict.de
Datum:        27.05.2016 10:02
Betreff:        Re: Re: [Blue Ocean] A new user experience project for Jenkins
Gesendet von:        jenkins...@googlegroups.com

---

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com

.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b230c4c2-2cdc-4c3c-827c-aba2d2c009f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Dumay]

Don't worry - nothing will disappear :)

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/Y9uzX4jVCsw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/OF074E4603.A0BED45A-ONC1257FC0.002E40EC-C1257FC0.002E4722%40gauselmann.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

On 27 May 2016 at 07:59, Craig Rodrigues <rod...@freebsd.org> wrote:

Hi,

The new Jenkins UI looks nice, and will be a big improvement over the existing UI.

The original selling point of Jenkins was that even with the simplistic forms-based UI,

someone could fill out a relatively simple form, and have a continuous integration pipeline.

I have met people who were general devops and scripting people, and could use Jenkins quite nicely.

While I understand the motivation for Pipeline (previously known as Workflow), I can't say I'm very happy with the results.

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.

So in my personal opinion, this is a sign of People Doing Things Wrong™

By this I mean that your Jenkinsfile should *not* be doing complex things. You should have shell scripts or equivalent to do the complex functionality. That lets you test each individual step in the phase on local developer machines. Then your pipeline should end up mostly being

node {

  try {

    sh "..."

    stash ...

  } catch (...) {

    sh "..."

  } finally {

    sh "..."

  }

}

input "..."

node {

  unstash

  sh "..."

}

 

Ok you may have to chain parameters between steps, etc. but what I see people doing instead is building up a whole big set of logic in the Jenkinsfile.

Now there is nothing "wrong" in building up that login in your Jenkinsfile... but in my view it is Wrong™ because:

• You now can only test this logic by running Jenkins builds.
• You cannot unit test this logic, you can only run manual acceptance tests on the whole script
• You will need to battle with the script approval process if security of your instance is important to you
• You have tied yourself to Jenkins (which initially seems tempting for Jenkins, but people who feel tied to a system are then not free to explore other options and probably are more correctly tied to a "specific way of doing things", so they cannot even explore alternatives *within Jenkins*... then when they finally get fed-up they blame Jenkins rather than their choices in how to use Jenkins... so it ends up being a loss of Jenkins when people tie themselves to "their way of using Jenkins")

• Documentation for Pipeline scripts isn't that great (although it has definitely been improving).  In all honesty, I cannot point a junior scripting person to write a good Pipeline script for developing a build Pipeline.
  

Documentation will improve. 

• The durable task plugin which invokes shell commands on Unix, and batch jobs on Windows goes through an elaborate method for invoking shell commands.  It is very, very difficult to grab the exit status of commands, stderr, stdout, etc.  For a while, these wrappers would do things like not detect when a command had terminated, etc. (Looks like this has been fixed now)

I hear you. It is a trade-off but being restartable is too much of a killer feature, so I view it as worth the pain of some initial bugs. 

• It is very hard to figure out how to cancel a running Pipeline job.  The UI link to "Click here to cancel" a Pipeline job is hidden in the build output, and often doesn't work.

I hear you and feel your pain too.

 

I understand that Jenkins is going through a big transition period.  Hopefully at the end of the road, things will be much better.

However, at this point in time, I would say that in many ways, the current direction is worse than the old way of doing things with the old Jenkins UI.

The old way has problems, but it was easy to figure out, and didn't have a lot of these intermediate layers that try to abstract things out,

but make things harder to figure out what is going on.

--

Craig

On Thu, May 26, 2016 at 3:21 PM, James Dumay <jdu...@cloudbees.com> wrote:

Today we’ve made the source code available on Github, written a blog post and created a video explaining the project in more detail. We will be posting more updates to both the blog and mailing lists when there are more updates to share.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAG%3DrPVdhtQabPM4PjowXGssk-Rpr7X6%3DfQZASCZo9cq99vTfcQ%40mail.gmail.com.

[Stephen Connolly]

For what it is worth, this last point is not just a problem for Jenkins, we have the same issue with Maven.

Do you not like Maven? Perhaps what you really don't like is that the people who wrote your pom.xml chose to make it a 10,000+ line epic rather than encapsulate the logic into custom plugins and a custom lifecycle.

If you are Doing Maven The Right Way™ then your pom.xml should be

<project>

  <modelVersion>4.0.0</modelVersion>

  <!-- optional -->

  <parent>

    ...

  </parent>

  <!-- /optional -->

  <groupId>...</groupId>

  <artifactId>...</artifactId>

  <version>...</version>

  <packaging>custom-packaging</packaging>

  <dependencies>

    ... insert dependencies here ...

  </dependencies>

  <build>

    <plugins>

      <plugin>

        <groupId>...</groupId>

        <artifactId>custom-plugin</artifactId>

        <version>...</version>

        <extensions>true</extensions>

      </plugin>

    </plugins>

  </build>

</project>

If you have anything more that the above then you have chosen to fight Maven. When you fight Maven, Maven always wins the war... which means you loose

Other build systems (i'm looking at you gradle) make it easy to embed small bits of custom logic and stave off having to stop for a second and think about that custom logic and then embed that logic into a Maven plugin... now that is indeed tempting for the once off project... but every time you release a new version of that project, those are repeated builds. If the process is really a once-off, just capture the output and check it into source control ;-) 

It is much better to slow down for a couple of minutes and encapsulate that logic into a custom plugin that can make reuse easier.

(Note I will agree with anyone who complains that writing Maven plugins is not as easy as it should be... but that is a different story that results from most people refusing to even try)   

[Ginga, Dick]

For the record, I have occasionally replied to threads with the same concern below: pipeline jobs require Groovy programming experience. I would much rather see a robust set of gadgets and widgets to choose from. Perhaps some build/release teams are composed of programmers. I am an experienced programmer in several languages, just not Groovy. But most teams are scripters: batch and shell.

 

Still, the fastest way to CI is picking and choosing standard known build and post build steps. Then maybe proceeding into Groovy for specific, local, requirements,

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyqp%3DwDXDc%2B-T_ejsk6Q5KMq%2BX1XAcZQuk9P7zFAnf8DA%40mail.gmail.com.

[Maciej Jaros]

Craig Rodrigues (2016-05-27 08:59):

Hi,

The new Jenkins UI looks nice, and will be a big improvement over the existing UI.

The original selling point of Jenkins was that even with the simplistic forms-based UI,

someone could fill out a relatively simple form, and have a continuous integration pipeline.

I have met people who were general devops and scripting people, and could use Jenkins quite nicely.

While I understand the motivation for Pipeline (previously known as Workflow), I can't say I'm very happy with the results.

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.
  
  

• [...]
  

Groovy is not my thing either. The syntax is not very hard, but using it with Jenkins is just trail and error. There are some changes from version to version and no central place to learn from.

I think this would be solved by providing recepies that would be updated for each Jenkins version. Some recepies ideas:

1. How to read a build parameter and conditionally run some shell script.
2. How to trigger build of another project.
3. How to trigger build of another project with some static parameters of various types.
4. How to trigger build of another project passing all parameters from current job/build.
5. How to copy artifacts from another project.
6. How to send files over SSH.
7. How to execute scripts over SSH.

Regards,
Nux.

[Maciej Jaros]

Stephen Connolly (2016-05-27 12:12):

On 27 May 2016 at 07:59, Craig Rodrigues <rod...@freebsd.org> wrote:

Hi,

The new Jenkins UI looks nice, and will be a big improvement over the existing UI.

The original selling point of Jenkins was that even with the simplistic forms-based UI,

someone could fill out a relatively simple form, and have a continuous integration pipeline.

I have met people who were general devops and scripting people, and could use Jenkins quite nicely.

While I understand the motivation for Pipeline (previously known as Workflow), I can't say I'm very happy with the results.

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.

So in my personal opinion, this is a sign of People Doing Things Wrong™

By this I mean that your Jenkinsfile should *not* be doing complex things. You should have shell scripts or equivalent to do the complex functionality. That lets you test each individual step in the phase on local developer machines. Then your pipeline should end up mostly being

But you cannot test everything locally, because you e.g. don't have build parameters, you might not have certain SSH credentials defined... That said I do tend to move everything to scripts, but this really defeats the purpose of almost all Jenkins plugins... And plugins gives you some integrations (especially with credentials) you don't have in scripts. And it's much easier to add build step for triggering e.g. call of another project and passing all parameters to it from current build (which BTW is overly hard with Groovy).

Regards,
Nux.

[Kent Johnson]

James, this looks really valuable and useful. I am looking to create one or two video training courses involving the Pipeline plugin suite. it is great to see the work you have done with Blue Ocean. Is Blue Ocean the future of the Jenkins UI? If so, I'd like to build the training courses around the new UI. I could do things in the new and the old, though if Blue Ocean is certainly the way of the future then I may as well focus on that.

Thanks for all your work to make the Jenkins user experience better.

[Stephen Connolly]

The Jenkins specific tasks should be mostly single purpose and logicless in my view.

The complex logic should be testable outside of Jenkins.

But building complex logic in groovy "just because it is there" and not "because we cannot do it elsewhere" is the problem my rant is directed at

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fac125e7-9e6c-46f1-bbe7-42067660d98c%40mol.com.pl.

For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Arnaud Héritier]

+1000 with this Stephen

I think you are taking a good blog post idea :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxSo6%3D9WaaBUZYxdYfMsj%3DRgbcrQyO3F3J%3D2oUuXcuoFA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Michael Neale]

BTW the github repositories have been "transferred" (ownership) into the jenkinsci org fully now (old links automatically redirect). 

[Kohsuke Kawaguchi]

Some of those are in https://github.com/jenkinsci/pipeline-examples

[Craig Rodrigues]

On Fri, May 27, 2016 at 3:12 AM, Stephen Connolly <stephen.al...@gmail.com> wrote:

On 27 May 2016 at 07:59, Craig Rodrigues <rod...@freebsd.org> wrote:

Here are some of the pain points I've encountered with Pipeline scripts:

• Other than the most trivial of scripts, you need to be a knowledgable Groovy programmer.  For example, to make a global variable, you need to use a @Field.  (What?!)  Most scripting and devops people that I know don't really know Groovy.

So in my personal opinion, this is a sign of People Doing Things Wrong™

By this I mean that your Jenkinsfile should *not* be doing complex things. You should have shell scripts or equivalent to do the complex functionality. That lets you test each individual step in the phase on local developer machines. Then your pipeline should end up mostly being

I have written Jenkinsfiles as you describe where the Jenkinsfile is "simple", and it calls external scripts

written in other languages (Bourne shell, Python, etc.).

However, even with Jenkinsfiles that are not doing complex things,

things can get very confusing very quickly.  Multiple people have asked about global variables in Jenkins scripts,

and get really confused when they read that using @Field will eliminate syntax errors.

Here are a few threads on this topic:

https://groups.google.com/d/msg/jenkinsci-users/P7VMQQuMdsY/bHfBDSn9GgAJ

https://groups.google.com/d/msg/jenkinsci-users/rQe45k6Uu3E/_7l3eZHIAwAJ

There have been a few questions on the mailing list about how to refactor Jenkinsfiles into common files that can be included:

https://groups.google.com/d/msg/jenkinsci-users/cmFUKUW4cWI/X6vHGK15AwAJ

Personally, I've found this to be unintuitive, and the recommended strategy of using workflow-cps-global-lib

is very weird and uintuitive.

You may disagree with me, but my experience is though Pipeline is a nice DSL,

as a script writer, you can't hide the fact that Jenkinsfiles are Groovy code.

Having a good understanding of Groovy and how the Groovy Pipeline code integrates with Jenkins core

is critical for being successful with Pipeline (maybe this will become less necessary as Pipeline matures and stabilizes).

Not all devops people who work with Jenkins are Java/Groovy hackers, so this can be a bit problematic,

in terms of scaling and maintaining complicated workflows based on Jenkinsfiles.

--

Craig

[nicolas de loof]

2016-05-27 20:34 GMT+02:00 Stephen Connolly <stephen.al...@gmail.com>:

The Jenkins specific tasks should be mostly single purpose and logicless in my view.

The complex logic should be testable outside of Jenkins.

But building complex logic in groovy "just because it is there" and not "because we cannot do it elsewhere" is the problem my rant is directed at

This was my exact concern with build-flow, as I've seen more and more people abuse it (imo) using more and more groovy logic there.

My preference goes to very basic pipeline scripting to inject credentials, then invoke a file I use to name Jenkinsfile.sh, where all the build take place ... and that I can test on my computer.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxSo6%3D9WaaBUZYxdYfMsj%3DRgbcrQyO3F3J%3D2oUuXcuoFA%40mail.gmail.com.

[Thorsten Scherler]

Hi all,

I will first take the opportunity to introduce myself. I am Thorsten Scherler one of the "new faces" and since the beginning of the year one of the front-end developer of blueocean. I have a long track record in open source development mainly in the ASF, where I was contributing mostly to the Cocoon based projects (Lenya, Forrest and Coocon). Weapon of choice had been java and xslt back then. Since around 3/4 years I started to switch to node.js and javascript as preferred technology stack. ATM I am the "react guy" in the blueocean team.

I used hudson/jenkins since the beginning with different technologies and projects. Last year I was lucky to had the opportunity to be on the team that created http://www.kaba.com/exivo which is 100% based on js, node.js, CQRS, Distributed Domain Driven Design and React.js. I mention this since we did something like "pipeline" with dependent jenkins projects but based on "normal" build jobs (of course there had not been a cool overview of the steps and how there had been connected). Only a couple of developer where able to fix the build scripts when things started to get weird since it were a good mix of docker, shell and js script magic and quite fragile. Anyway we made it work to the point where we implement a kind of CD, not pretty but fully functional. 

When I wrote my first Jenkinsfile for the jenkins-plugin-site I struggled a bit as well to "use" groovy to write it, but as Stephen stated I did the "dirty" work in my "normal" shell scripts and this way had nearly no contact to use groovy at all and my scripts are as testable as they had been before. Since I wrote the views on pipeline/multibranch/PR I had to create a couple of pipeline scripts and Jenkinsfile to get real data in my development environment. I found the widget that generates you groovy code snippet very helpful, but as said I did not do rocket science just created pipelines to generate me some testing data.

In my opinion in the future pipeline scripts should be created by drag and drop, so I could use Jenkins to generate me a Jenkinsfile without having to see the generated code at all. A "manager" without technology knowledge (if that still exists nowadays) should be able to create a CD pipeline only using a smart wizard.

Regarding the principal discussion whether there should be something like Jenkinsfile I think we only have to look on all the Dockerfiles, .travis.yml etc. to realized that this is a common practise and further brings lots of advantages. You keep the information on how jenkins/docker/travis should treat your project in your project and do not have to configure any jenkins/docker/travis instance to treat your project right. That is the killer feature which would have saved my last project A LOT of TIME since instead to configure our 3/4 different staging environments in the running instance we would have just created a Jenkinsfile which described the build/testing pipeline and reused it in all our env.

Anyway I hope as soon you have played around a bit with blueocean you will find that what it does right now it does much better then the current alternative in direct comparison. What it will do in the future depends on YOU since it an open source project after all. ...as always for any given OS-project patches are welcome. ;

salu2

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fac125e7-9e6c-46f1-bbe7-42067660d98c%40mol.com.pl.
For more options, visit https://groups.google.com/d/optout.

[James Dumay]

Certainly it would be great to see your training updated to include Blue Ocean! Though it is very alpha right now and needs some more time to bake before its ready for everyone to use.

I'd like to think that its the future of the Jenkins UI but that is up to the community to decide. And you are very welcome – I am extremely happy you like it.

[Utsav Kumar]

I am not able to approve a stage using blue ocean UI (when using the input step). Neither it shows something like "Waiting for your approval" when an approval is required.

[Michael Neale]

Hi Utsav - yes sorry about that - it hasn't been implemented yet. 

There are a few tasks in progress that make this up: 

 https://issues.jenkins-ci.org/secure/RapidBoard.jspa?rapidView=171&view=planning&selectedIssue=JENKINS-40298&epics=visible&selectedEpic=JENKINS-38490

Some code has been merged to support some of this, but not hte UI yet. It isn't just a yes/no, but input can ask for values as well (which is where it gets a little complicated)