Details
-
Type:
Bug
-
Status: Reopened (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: workflow-cps-global-lib-plugin
-
Labels:None
-
Environment:linux rhel7.2
jenkins 2.19.2
up to date 'workflow' set of plugins (on stable update center)
-
Similar Issues:
Description
I have this situation where :
- I have some jobs that gets sources from a SCM, and performs a 'poll SCM' hourly
- I have a 'global pipeline lib' defined, on another SCM (doesn't matter really, what atters is it's not in the same source tree s the jobs)
My issue is that any commit to the 'global pipeline lib' SCM will be detected by all the jobs that have a 'poll SCM' configured.
I wish I can exclude the global lib from polling.
(and yes, I know, polling is evil, whenever I can I have triggers configured on modern scm to push jobs, but sometimes it's just not possible, believe me you don't want to know all the why's)
Attachments
Issue Links
- duplicates
-
-
- Open
-
-
JENKINS-41497 Poll SCM and Timer triggers include "Changes" for a Pipeline for any/all Shared Libraries
-
- Reopened
-
- relates to
-
-
- Resolved
-
Activity
For everyone who may still facing this problem, please refer to the workaround mentioned here. I can confirm it solves the problem.
Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file?
Brian Villanueva
added a comment - Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file? "Include @Library changes in job recent changes" did fix this issue for us. However, importantly, we had to restart our Jenkins server for this to take effect.
Chris Knight
added a comment - "Include @Library changes in job recent changes" did fix this issue for us. However, importantly, we had to restart our Jenkins server for this to take effect. For me, "Include @Library changes in job recent changes" did stop the changes from appearing in change log but a change in shared library is still triggering the build.
Also facing this issue, we have lots of microservice CI/CD jobs configured, which depend on the shared library, any change made to the shared lib will trigger all downstream jobs.
Looking forward to the fix.