-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.263.3
Git plugin 4.8.2
In the Source Code Management section of a Jenkins job configuration, if you select Git and configure the two additional behaviors "Polling ignores commits in certain paths" and "Shallow clone", then the job is triggered by commits that should be ignored based on their paths.
To reproduce:
- Create a new freestyle Jenkins job.
- In the Source Code Management section of the configuration, specify Git. In the Repository URL field, specify the URL of some Git repository.
- In the Additional Behaviours subsection, select "Polling ignores commits in certain paths", and enter some path constraint in the Included Regions field, such as someDir/.*.
- Also in the Additional Behaviours subsection, select "Advanced clone behaviours", select the "Shallow clone" checkbox, and enter a shallow clone depth of 1.
- In the Build Triggers section, select the "Poll SCM" checkbox and enter the schedule * * * * * (meaning poll every minute).
- Save the configuration. Wait for some commits to the Git repository. Observe that the job is triggered by every commit to any part of the repository – not just ones whose paths match the Included Regions pattern.
More generally, it seems to be that, if your "shallow clone depth" is some number n, then, if there have been at least n commits to the entire repository since the last build, the job is triggered regardless of whether the commits are to ignored regions.
Shallow clone depth brings all sorts of complications to the plugin. Based on benchmarks performed by GitHub and my own experiences with shallow clone, I've been recommending that people prefer narrow refspecs and reference repositories rather than using shallow clone.
I agree this is a bug. I don't plan to work on this bug.