Jenkins 2.0 Proposal: Pipeline as code front and center

[R. Tyler Croy]

I've posted this to the blog which I'm very excited about but is also relevant
to this list:
<http://jenkins-ci.org/content/jenkins-20-proposal-pipeline-code-front-and-center>

Please see <https://issues.jenkins-ci.org/browse/JENKINS-31152> for
comments/votes/etc


- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------

[Slide]

Honestly, I'm kind of getting tired of hearing about how workflow will solve all of my problems and cancer. I'm glad that people like it, but honestly, for a new user of Jenkins, workflow is so overkill. It's great having an option for people who are build engineers and whatnot, but please don't overlook people who are tasked with setting up a build server and have very little experience with code. I'm sure there are things being worked on to make workflow easier, and that's great. I'm really considering other tools at this point because of workflow being pushed so hard. I've heard people say I shouldn't worry, but when you have several of the major contributors looking at workflow and fatal issues like [1] and [2] around for over a year affecting users, its pretty disheartening.

1 - https://issues.jenkins-ci.org/browse/JENKINS-22853
2 - https://issues.jenkins-ci.org/browse/JENKINS-23271

--
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/20151028175559.GX2450%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

[Ginga, Dick]

I’ll add some support to Slide’s comments below. I don’t want to be a Groovy expert programmer to get builds and continuous integration working. I personally like (as in very much like) the Build Flow plugin. It is just enough functionality with just enough programming access to some underlying functions to be perfect for our CI implementation (and my capabilities). But I would like to be able to have a Build Flow Build step (as in not just a job type) that I can use with other Build Steps. But I don’t think this is on anyone’s to-do list.

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

[Stephen Connolly]

My view is that there are three paths people will follow in using Jenkins:

* the traditional path will predominantly use freestyle jobs as the engine of work

* the modern path will predominantly use s/literate/new name/ jobs as the engine of work

* the gradle-fanboys will predominantly use s/workflow/pipelines/ as the engine of work.

All three groups will - to my thinking - use s/workflow/pipelines/ as the coordinator of work.

None of these three groups souls be seen as inferior or superior, as there are trade-offs for each path:

* freestyle/etc is a poor fit for refactoring the build process on a branch

* s/literate/new name/ is a poor fit for organisations that want to block ordinary users from changing the build (as they can control the build just by committing to SCM and SCMs like Git do not have path based access controls)

* s/workflow/pipelines/ has some baggage from its groovy DSL parser engine that can be viewed as overkill for lots of simple build jobs

But when you get to coordinating individual units of work, s/workflow/pipelines/ really comes into its own.

NOTE: the above is my personal opinion expressed outside of work hours

- Stephen

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

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

--
Sent from my phone

[R. Tyler Croy]

(replies inline)

On Wed, 28 Oct 2015, Slide wrote:

> Honestly, I'm kind of getting tired of hearing about how workflow will
> solve all of my problems and cancer. I'm glad that people like it, but
> honestly, for a new user of Jenkins, workflow is so overkill. It's great
> having an option for people who are build engineers and whatnot, but please
> don't overlook people who are tasked with setting up a build server and
> have very little experience with code.

So this work, AFAICT, doesn't remove some of the existing Web UI-based
configuration stuff, and I doubt it ever will.

From my perspective, the people who are tasked with setting up build clusters
are also in the "target demographic" for the Pipeline work. The fact that
there's the Jenkins Job Builder and a number of other tools that exist to try
to create Jenkins job XMLs is a total hack for sysadmins and engineers
supporting lots of similar projects.

I view the fact that I cannot apply a staging/delivery process to my job
configurations to be somewhat hypocritical in Jenkins, which I hope
some of the focus around "pipeline" helps alleviate.

Personally I would like to be out of the business of clicking mouse buttons to
set up jobs.

> I'm sure there are things being worked on to make workflow easier, and that's
> great. I'm really considering other tools at this point because of workflow
> being pushed so hard. I've heard people say I shouldn't worry, but when you
> have several of the major contributors looking at workflow and fatal issues
> like [1] and [2] around for over a year affecting users, its pretty
> disheartening.
>
> 1 - https://issues.jenkins-ci.org/browse/JENKINS-22853

Fortunately this looks like it's being addressed by Oleg \o/

> 2 - https://issues.jenkins-ci.org/browse/JENKINS-23271

Not sure about this one, but I definitely share your frustrations with tickets
sitting idle like this :/

There's definitely a lot to do around Kohsuke's proposal, the things we're
talking about aren't finished yet which is why they're listed as proposals in
the first place though :P

[Kohsuke Kawaguchi]

Thanks for your feedback.

The "you shouldn't worry" part is that the freestyle projects aren't going away, which Tyler & Stephen have already covered.

The way I read your comment is that you see the quality as the most important issue and when you see me talking about workflow, it rubs you in a wrong way because I am not talking about the quality. In other words, you are disagreeing with the prioritization, because if you really just didn't like workflow, all you need to do is to uninstall those plugins. Is that a fair way to summarize?

I take your point that I haven't talked anything about the quality improvements. I don't have a solid idea of which part of that space we can realistically address, but I can imagine there are things we can do --- for example maybe our spending more effort into stabilizing acceptance test, taking on longevity testing, or perhaps adding an alternative transport for master/slave communication, etc.

We should have a conversation like that indeed.

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

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

--

Kohsuke Kawaguchi

[Maciej Jaros]

I think there are two problems with workflow and other script related plugins:

1. There is slim-to-none documentation on Jenkins APIs. There is no single authoritative place to learn about available interfaces with basic to advanced examples of their usage. Frankly, I haven't found a good book about it either.
   
2. A killer feature would be to be able to convert build steps (at least some basic ones) to e.g. Groovy. This would greatly lower the barrier of converting from GUI based configuration to code driven job dentitions.

Regards,
Nux.

[Kanstantsin Shautsou]

s/Workflow/.?/ is of course interesting idea, but i looks like it has the gulf between the two sides. 

- Freestyle has barrier between build steps and Publishers that constantly causes headache for plugin devs. I tried add SimpleBuildStep support and got other problems (see jenkins PRs) with generic Run objects.

- Workflow seems solve many difficult cases, but adds other complexities like new mixed APIs, no input validations, no config migrations. Adding workflow support is impossible without busy @jglick help.

What i really expected - it fixes/improvements in Freestyle (that is really not a "free style" today) with base support for workflow APIs. This should allow having UI features (that was a really feature killer against other CI systems) and allow easily jump to DSLs. New comers will be able to have UI and advanced will be able to pick config.