SCM polling doesn't work when SCM config is defined on a parent job. about jenkins-inheritance-plugin HOT 10 CLOSED

Hi James.

Sorry for the late reply.

Thanks for your bug report. It might be comforting for you to hear that you are not alone. A user already reported this to us during the closed beta.

The issue boils down to this: The polling implemented by the SCM plug-ins only works if the SCM property is defined on the project itself, but not if it is inherited. This is because they usually spawn a "Periodic Work" that polls the project they're defined on regularly. As this logic resides 100% in the SCM plug-ins, we have not yet found a good way to intercept their polling and re-apply it to all child jobs that inherit the SCM property.

I also noticed that we forgot to add this to the wiki as a known issue. :(
This will be corrected ASAP.

We will keep you posted as soon as we find a solution for this issue -- preferably one that does not need the SCM plug-in maintainers to modify their code.

from jenkins-inheritance-plugin.

Great, thanks. Is this the same issue that affects the repository browser settings? The changes view doesn't seem to pick up the SVN repo browser settings from the parent build.

from jenkins-inheritance-plugin.

Two further questions:

• do you want this issue left open, and
• is this the correct forum for raising issues?

from jenkins-inheritance-plugin.

Yes, I wish to leave the issue open, as it is, strictly spoken, an issue with this plug-in. :)

And yes, GitHub is the correct forum to raise issues, as that is where the source-code for the released plug-in visible in Jenkins is coming from.

If you need to ask a question, instead of raising tickets, you can use our support mail-address: [email protected]

from jenkins-inheritance-plugin.

I have an experimental fix for this which appears to solve this and have a couple of questions regarding the soundness of the approach. There are two main pieces, wiring polling for child jobs into the the jenkins polling mechanism, and inheriting the related actions (on the child project page, for example).

I've gotten the polling to occur successfully by overriding 'Map<TriggerDescriptor,Trigger> getTriggers()' to return the inherited triggers. I added a method 'getAllTriggers(IMode)' modeled on the existing methods for other types. The implementation is in this gist: https://gist.github.com/afitz/19fe79c6a97be227ae54

Is there a better place (maybe an extension point) to to the transform of the inherited trigger to point it at the child project (currently this is happening in getRawField)? Secondly, the linked implementation suffers from the flaw that if polling is defined twice in the inheritance heirarchy it will return all of those triggers (which can result in weird behavior).

In order to get the SCM poll log action to display on the project page, and to use IMode.AUTO for trigger resolution with polling, I made changes to inheritanceLookupRequired(InheritanceProject, boolean) in InheritanceGovernor. I added a condition for Trigger.checkTriggers, and also changed the condition based on the StaplerRequest to return true for any URI that isn't the configure page. This should also be in the gist.

While this has worked for the scenarios I've tested the various related comments make me wonder if this is indeed unsafe (particularly the change to the request behavior).

Apologies for the use of a gist rather than pull request. I'm more than happy to contribute back any eventual fix, the plugin is great!

Thanks,
Adam

from jenkins-inheritance-plugin.

I just wanted to add some extra information to this issue, we have had a similar problem with our builds. If the SCM details are specified in a parent job the setting "Build when a change is pushed to GitHub" does not work (I think this setting relies on the github plugin but i'm not sure that is material info)

I think this issue is exactly the same as the "Poll SCM" not working but I can't confirm because I haven't looked into the guts of it.

My current workaround is to define the SCM at the Leaf job that you want to kick off, I know it sidesteps one of the main reasons for your plugin but it is ok until a fix lands.

from jenkins-inheritance-plugin.

Hi Adam.

Sorry for the extremely delayed response. We had a close deadline that suddenly popped up and had to pretty much drop development on everything else to focus on just that.

I had a look at your changes and it is looking good so for. As you've already seen by the "TODO" annotation for getTriggers() we had similar issues that you also encountered; namely that it was hard to avoid inheriting these triggers multiple times.
Come next Monday (2nd Dec.), we will look into your solution and see if we can extend it to avoid that issue.

As for your question, the merging of properties is already exposed by an extension point: "project.inheritance.InheritanceSelector". As the name implies, its role is to select which properties should be inherited and in what way. It gets a list of all properties of a specific type (Parameters, BuildSteps, SCMs, etc.) as an input. It can then decide if a specific element should be used (first-defined, last-defined, etc.) or whether all or a part of the properties should be merged.

This is for example how the merging of parameters is currently handled. It creates one big set of parameters from all parents.

The default behaviour, if no suitable Selector is present, is to select either the property that was defined last (for example for SCMs) or to create a long list of them (for example for BuildSteps).

This is probably the best place to merge the duplicated triggers.

We will check-back with you after next monday. :)

from jenkins-inheritance-plugin.

Hi Chris.

Thanks for your input. Your experience and ours do match up; pretty much all plug-ins that wish to automatically start builds based on some events make use of the same "Trigger" mechanism. This gives us the hope that we can fix them all with one patch-set.

Of course, the flip-side of that coin is that we need to make sure to handle that mechanism exactly like all those plug-ins expect, or we might get inconsistent behaviour or worse issues.

As stated in my response to Adam, we will take a look at it at the start of next week. Hopefully it's a good step in the right direction so that we can fix this long-standing and important issue sooner, rather than later.

from jenkins-inheritance-plugin.

Hi everyone.

This bug has been fixed via this commit: b1a1e61

It added support for inheriting triggers properly. To not break existing installations with this "experimental" feature (since many plug-ins make use of Triggers and we can't test them all at once), the feature will be disabled by default in v1.5.0 only. It will display a warning message announcing this new feature and how to enable it (or suppress the warning).

If everything works out right, it will be enabled-by-default in the future versions following v1.5.0.

Thanks again to you all for your helpful input on this matter.

I will be closing this issue now. If you find another issue with the new feature, please create a new issue, to cleanly separate pre-1.5.0 issues and post-1.5.0 issues.

from jenkins-inheritance-plugin.

Hi,
strangely i still see this issue in 1.5.3. triggers inheritance enabled.
if parents hold all git setting i see that my son jobs don't even try to poll.
if i put polling shedule in son jobs, i see that that polling is wrong, it checks "None" repository:

None Polling Log

Started on Nov 6, 2014 12:11:00 PM
Polling SCM changes on mtlbuild-001-018
Done. Took 19 ms
No changes

Why is that?
Will hooks work as described here:
http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/

from jenkins-inheritance-plugin.