Using "modules" it is possible to have a set of folders to be considered for change detection only. This helps a lot, but there are cases, where I need to ignore some specific files, e.g. when a special file is changed that contains the version info for my application – this file is used to (increment and) put the current version into my projects.
Even better would be to be able to parse the commit comment and filter out commits matching a regex.
- duplicates
-
JENKINS-7239 Support Excluded Regions in SCM Polling
-
- Open
-
-
-
- Open
-
[JENKINS-36614] Ignoring specific files or commit strings for change detection required
Mehrdad Mirreza
added a comment - Which "something"? He is talking about JENKINS-30189 . It is a desirable feature and I'm shocked it isn't in yet particularly since the Git Jenkins plugin supports this behavior (since 2014 version 2.2.9).
It is fairly trivial feature to add. I'll see if I can put a pull request.
Mehrdad Mirreza
added a comment - Well, for me there is a difference between filtering out specific commits entirely (JENKINS-30189) and ignoring changes in specific files.
Of course you would make the decision to trigger a build or not, based on one or more changesets, but my point is to be able to define some files as "not-triggering" and if you have only these files inside a changeset, then the changeset should not trigger a build.
The other solution, which is maybe easier to implement and is inside the focus of JENKINS-30189, but not convenient enough to use, would be to look after special phrases inside the commit description string (like {Jenkins:Ignore}) and then ignore that changeset as trigger.
Mehrdad Mirreza
added a comment - Well, for me there is a difference between filtering out specific commits entirely ( JENKINS-30189 ) and ignoring changes in specific files.
Of course you would make the decision to trigger a build or not, based on one or more changesets, but my point is to be able to define some files as "not-triggering" and if you have only these files inside a changeset, then the changeset should not trigger a build.
The other solution, which is maybe easier to implement and is inside the focus of JENKINS-30189 , but not convenient enough to use, would be to look after special phrases inside the commit description string (like { Jenkins:Ignore }) and then ignore that changeset as trigger. 
Duplicate of something filed long ago.