fine-tuning of SCM polling in a multi-branch pipeline project

[Ewgenij Gawrilow]

Hello,

could anybody more seasoned in Jenkins pipelines point me to some documentation or informal explanation of the behavior of SCM polling in the multi-branch context?
I'm trying to set up a pipeline running different test scenarios depending on some magic words in the commit message, or not doing anything (ideally not triggering any build at all) if these magic words are missing.  I've got stuck at several points where I couldn't find any explanations in the Wiki nor StackOverflow nor in this mailgroup:

 - Is it by intention or simply a bug that the option "Additional Behaviors -> Polling ignores commits with certain messages" set in the multi-branch pipeline project configuration is silently ignored?  The branch indexing happily triggers builds in all branches with new changes regardless the messages of last commits there.

 - What is the purpose of the branch job property "Override multibranch or organization branch indexing triggers" ?  How can they be overridden?

 - What are the rules of resolving "conflicts" between the polling policy for the multi-branch pipeline as a whole and particular policy assigned to a branch per properties() call in the Jenkinsfile?  For example, if the latter enables SCM polling without schedule, and a GIT commit notification arrives, would there be two builds in the same branch, one triggered by the notification directly and another one by the branch indexing?  Is "Property Strategy -> Suppress automatic SCM triggering" designed as a solution against this?  What about first builds for new branches, will they be suppressed as well - then no properties could be assigned to them?

 - and, finally, if nothing else helps and I can't avoid "empty" builds being triggered: is there a function making the current build disappear traceless, as if never started?  Kind of a transaction rollback?

Appreciating any hints very much,

Ewgenij

[Stephen Connolly]

On Wed 17 May 2017 at 11:33, Ewgenij Gawrilow <ewgenij....@o2online.de> wrote:

Hello,

could anybody more seasoned in Jenkins pipelines point me to some documentation or informal explanation of the behavior of SCM polling in the multi-branch context?
I'm trying to set up a pipeline running different test scenarios depending on some magic words in the commit message, or not doing anything (ideally not triggering any build at all) if these magic words are missing.  I've got stuck at several points where I couldn't find any explanations in the Wiki nor StackOverflow nor in this mailgroup:

 - Is it by intention or simply a bug that the option "Additional Behaviors -> Polling ignores commits with certain messages" set in the multi-branch pipeline project configuration is silently ignored?  The branch indexing happily triggers builds in all branches with new changes regardless the messages of last commits there.

That should not be configurable and I am working on UI refactoring that will remove the confusing option

 - What is the purpose of the branch job property "Override multibranch or organization branch indexing triggers" ?  How can they be overridden?

 - What are the rules of resolving "conflicts" between the polling policy for the multi-branch pipeline as a whole and particular policy assigned to a branch per properties() call in the Jenkinsfile? 

Per job polling is always disabled in multibranch.

There is a single poll/central event processing handled by the multibranch project.

For example, if the latter enables SCM polling without schedule, and a GIT commit notification arrives, would there be two builds in the same branch, one triggered by the notification directly and another one by the branch indexing?  Is "Property Strategy -> Suppress automatic SCM triggering"

I will probably be refactoring to remove that and replace with a more coherent solution

designed as a solution against this?  What about first builds for new branches, will they be suppressed as well - then no properties could be assigned to them?

 - and, finally, if nothing else helps and I can't avoid "empty" builds being triggered: is there a function making the current build disappear traceless, as if never started?  Kind of a transaction rollback?

Appreciating any hints very much,

Ewgenij

--
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/8ff9a3c1-d1e5-4dd1-8ddc-aa919cbc605e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone