Comments (10)
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.
Related Issues (20)
- "Restrict where this project can be run" doesn't work and won't maintain it's configuration
- triggers inheritance doesn't work at ver 1.5.3. HOT 1
- Doesn't work with Parameterized Trigger Post-build Actions HOT 1
- SCM parameters not separated
- Defaults of inherited parameters not passed when triggering a build via a token HOT 14
- Parameterised build with "run parameter"
- Add support for multijob HOT 2
- WARNING: Found unresolveable reference to
- Support for the Jenkins Job DSL
- Thread deadlock
- Exception in project configuration under Jenkins 2
- Is this project maintained? HOT 2
- Old incompatibilities fixed in 2.0.0 ? HOT 1
- CRITICAL Can't select (reference) parent parameters in child job
- Post method fails with error 400 if we are posting config.xml to an inheritance project HOT 1
- Inheritable parameter reference doesn't seem to work if jobs created under folder
- SCM polling is not working.
- Documentation for inherited parameters not shown
- Add missing variable description in InheritableStringParameterDefinition/index.jelly
- Host plugin in jenkinsci organization?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jenkins-inheritance-plugin.