Recorder/Notifier execution order not enforced by Jenkins

[Arnaud Tamaillon]

Hello,

While the Recorder, then Notifier order is documented in the documentation:

• http://javadoc.jenkins-ci.org/hudson/tasks/Recorder.html
  
• http://javadoc.jenkins-ci.org/hudson/tasks/Notifier.html
  
• http://javadoc.jenkins-ci.org/hudson/model/Build.html
  

, it seems not to be enforced by Jenkins.

https://issues.jenkins-ci.org/browse/JENKINS-37299 is a reproducer of the issue. For the anecdote, kohsuke did the 33df3bc7602e46fdbedb4966302d6dae06fe5b1e change to the claim plugin to fix http://jenkins-ci.361315.n4.nabble.com/claim-plugin-text-finder-plugin-conflict-td385850.html#none (up-to-date url matching the one in the commit message) 8 years ago, which is the exact same issue reported in this ticket.

kohsuke introduced the Recorder/Notifier distinction in Jenkins core change b63f162f75964f52118755105bee676d29da8828.

IIUC, this change has some order-enforcement mechanism via the order of publishers in the job ui, through the Publisher.DescriptorExtensionListImpl, which sorts the publishers according to their types.

This behavior can still be seen in Jenkins job configuration ui, where the potential publishers list is sorted by types, and where adding one in the jobs adds in at the same position that the one it has in the list of potential publishers.

I failed to find any other mecanism taking care of this order in the rest of the code.

While this was probably enough at some point, now that we can reorder steps by drag & dropping, and that we can do declarative pipelines, I think it is void today.

Is this issue already known from core team ? Are there any plans that will make it void for the future, or is it something that needs to be fixed?

Arnaud

[Jesse Glick]

On Fri, Jan 5, 2018 at 4:25 PM, Arnaud Tamaillon <arnau...@gmail.com> wrote:
> now that we can reorder steps
> by drag & dropping, and that we can do declarative pipelines, I think it is
> void today.

Built-in step order is ignored by Pipeline—whatever you ask to run,
Jenkins runs, in that order. I doubt any core dev is going to spend
time changing the behavior now for the benefit of freestyle projects;
there is a risk of regression and the workarounds are simple.

[Arnaud Tamaillon]

Built-in step order is ignored by Pipeline—whatever you ask to run,
Jenkins runs, in that order. I doubt any core dev is going to spend
time changing the behavior now for the benefit of freestyle projects;
there is a risk of regression and the workarounds are simple.

That's more or less what I suspected.

To me, the main issue is that this users cannot discover this issue by themselves, especially if the issue arise in specific rare conditions.

Maybe a simple textual warning at run time in the build log about inconsistent order would be helpful, and not much of an investment?

This could also be done for pipeline users, so that they have a chance to discover the issue.

What do you think about this?

Arnaud

[Daniel Beck]

> On 6. Jan 2018, at 10:17, Arnaud Tamaillon <arnau...@gmail.com> wrote:
>
> This could also be done for pipeline users, so that they have a chance to discover the issue.
>

"The pipeline will behave as you defined it, rather than artificial constraints designed for freestyle jobs" will not make a good warning.

[Ullrich Hafner]

Well this problem is not related to pipelines. Also freestyle jobs suffer from the same problem. If the user reorders post build steps then boom (see JENKINS-22394)! Maybe the ‚order‘ attribute should be marked as deprecated. 

[JENKINS-22394] https://issues.jenkins-ci.org/browse/JENKINS-22394

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/48371746-B524-4143-B346-2F2D77EADC1F%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

[Arnaud Tamaillon]

"The pipeline will behave as you defined it, rather than artificial constraints designed for freestyle jobs" will not make a good warning.

Agreed :)

I was more thinking about something like 'Warning: Recorder xxx is configured to run after Notifier yyy, which might result in unexpected results'.

To me it is more about making sure that a Jenkins user has a direction to search when something behave abnormally, without having to go to the plugin source code to check if the plugin is marked as a Recorder or a Notifier, which is today the only way to diagnose for certainty that something is wrong with the definition used.

The fact that we have issues reported about incorrect behaviors of plugins is also a sign that it is not matching users expectations.

At the very least, it means the javadoc is incorrect, and that plugins developers are developing publishers with incorrect assumptions.

[Jesse Glick]

On Sat, Jan 6, 2018 at 5:25 AM, Arnaud Tamaillon <arnau...@gmail.com> wrote:
> plugins
> developers are developing publishers with incorrect assumptions.

Pretty much any publishers developed for freestyle only will have all
sorts of weird assumptions. C.f.

https://jenkins.io/doc/developer/plugin-development/pipeline-integration/#run-listeners-vs-publishers