-
Bug
-
Resolution: Unresolved
-
Major
-
Redhat Linux 5.8 , Jenkins 1.538, Git plugin2.0
-
Powered by SuggestiMate
For our continuos Integration we are using maven-release-plugin. For which we would like to ignore commits from Jenkins user which is incrementing artifact version and doing commit.
With Polling SCM and using "Polling ignores commit from certain users" to ignore commits by Jenkins user which is not working as expected and going to infinite loop.
- duplicates
-
JENKINS-19001 Git polling not detecting changes since 1.1.1
-
- Closed
-
- is related to
-
JENKINS-25048 Git plugin ignores included/excluded paths when triggering build on commit notification
-
- Open
-
-
JENKINS-10131 Git polling shouldn't need a workspace on a slave.
-
- Closed
-
[JENKINS-20607] Gerrit trigger caused git plugin polling to not ignore commit from certain users
Workaround: enable the "force polling using workspace" additional behaviour.
The underlying cause is an overly optimistic implementation of "fast" polling (by comparing only the last built commit and the current branch tip via git ls-remote). "Fast" polling doesn't download commits until after a build decision has been made, which means there's no way for the commit inspection rules to evaluate.
I've got [a pull request](https://github.com/jenkinsci/git-plugin/pull/181) open that fixes the problem by making commit inspecting rules force the slow path; the "force polling using workspace" additional behaviour does the same thing.
@Owen, I tried "Force Polling using workspace" option which didnt work in my case. I see that your pull request is not yet merged,once done i'll try it again.
Hitting this issue and the suggested workaround works for us.
Jenkins ver. 1.546
Jenkins Git plugin 2.0.1
We use excluded regions as well as excluded users heavily.
I also hit the issue, the workaround does not work for me, too.
I am using Jenkins ver. 1.551 with Git Plugin 2.01. I upgraded from 1.543 and 2.0 which it was not working too.
I also thought that this workaround was not working, but my mistake was actually that my regex was invalid. I found the problem when I checked my Jenkins log files looking for something else. I wanted to mention it in case anyone else was making the same mistake. I was trying to use something like "somedirectory/**" (because that what I'm used to using with a lot of Java based applications), but the correct regex would be "somedirectory/.*".
Same here. Workaround does not work for me. Does it matter what order the additional behaviors have?
My concrete problem:
2 branches: A and B
Job is parameterized so I can tell which branch to build.
Job scans both branches (by origin/**) every hour to check for changes.
Jenkins raises the build number within the pom files.
Commits by Jenkins user should be ignored and not cause the job to run.
When the last build was in branch A and changes in branch B (by scanning origin/**) are detected, the build for branch B gets kicked off correctly. Unfortunately also changes in branch A (raised build number by jenkins)are detected an d another build gets scheduled, leaving this message in the log:
Multiple candidate revisions
Scheduling another build to catch up with (BUILD) my faulty job
From that point on, the job switches between branch A and B every time and is scheduling the other branch to get build every time causing an endless loop.
This works with:
GIT Client 1.16.1
GIT plugin 2.3.5
Jenkins 1.580.1
What caught me is the syntax of the config. I was only putting in the email, and it turns out I need to be far more explicit.
For instance, my Git commit username is:
"First Last <first.last@example.org>"
For the Jenkins config field, I added:
"First Last"
"First Last <first.last@example.org>"
For this to start working.
Using current last versions of plugins ( git 2.4.0 and git-client 1.19.0 )
- It works in a free-style job (commits ignored by user name)
- It doesn't work in a workflow job ( https://wiki.jenkins-ci.org/display/JENKINS/Workflow+Plugin version 1.10 ) using Workflow Script from SCM
I got the same issue with :
Jenkins ver. 1.609.3
Git plugin ver 2.4.0
Build job gets triggered by all the commits, even though I specify the username, message,path to be excluded.
I tried the workaround above yet It doesn't work.
Any idea ?
Alright,
After debugging, I found out the root cause:
In case of ignoring the username , actually ,jenkins using <firstname lastname> string ,it's not your git username ,but the profile lastname firstname, (I am using Stash). So let's say my Git (Stash) username is abc, my firstname is Tuyen, my lastname is Lieu:
TO make it work ignoring the commit from my username, put this : Tuyen Lieu.
In case of message, from the source code, it turns out to be that Jenkins automatically add "\n" to the end of the comment. i.e :
"this is my comment" (stash) will be like "this is my comment\n" when jenkins parses the commit metadata.
So to correct this, add "\n" to your pattern : ".*[this]\n.* "
Hope it helps.
I guess this is not the same issue when using Jenkins Workflow Plugin.
I can see this git polling log:
Started on Oct 15, 2015 9:08:29 AM Using strategy: Default [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url git@github.com:organization/project.git # timeout=10 Fetching upstream changes from git@github.com:organization/project.git > git --version # timeout=10 using GIT_SSH to set credentials deploy user on github > git -c core.askpass=true fetch --tags --progress git@github.com:organization/project.git +refs/heads/*:refs/remotes/origin/* Polling for changes in > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10 > git log --full-history --no-abbrev --format=raw -M -m --raw 74072d171ab432943380ab42ab14950a1149bb04..bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f # timeout=10 Ignored commit bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f: Found excluded author: deployuser Ignored commit 3f417d8e3ae6e9c7e024a41d719cb08e7dba594f: Found excluded author: deployuser Using strategy: Default [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop) using GIT_SSH to set credentials deploy user on github > git --version # timeout=10 > git -c core.askpass=true ls-remote -h git@github.com:organization/project.git # timeout=10 Found 7 remote heads on git@github.com:organization/project.git [poll] Latest remote head revision on refs/heads/develop is: bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f Done. Took 2.5 sec Changes found
It is using git "user.name" because I have also tested with random users (deploy ssh keys not related with any github user) setting an arbitrary user.name property.
As you can see, 'deployuser' is detected and excluded in the first polling, but later, changes are detected and build is fired.
Using same polling configuration from a free-style job works like a charm.
I tested again with additional "Use commit author in changelog" behaviour. It returned my author name < Lieu, Tuyen>
@Override public Boolean isRevExcluded(GitSCM scm, GitClient git, GitChangeSet commit, TaskListener listener, BuildData buildData) { String author = commit.getAuthorName(); if (getExcludedUsersNormalized().contains(author)) { // If the author is an excluded user, don't count this entry as a change listener.getLogger().println("Ignored commit " + commit.getCommitId() + ": Found excluded author: " + author); return true; } return null; }
As you can see from the method above, without the "Use commit author in changelog", it will return author name.
In my case, it returns author name with/without this option, which seems quite strange. I guess Stash may notify some funny metadata.
Have you tried to put some breakpoints at the above method in hudson.plugsin.git.extensions.impl.UserExclusion ?
sergiorc your comment that it does not work for the workflow case is a very different case than the case described in this bug. I'm not sure the workflow use of the git plugin enables all the configuration options available in the git plugin, especially things that are as complicated as excluding commits by user. I think you'd be better served by reporting a separate bug, rather than just including a comment in this bug report.
Hitting the issue and the workaround doesn't work for me.
Using Jenkins ver. 1.635; Git plugin 2.4.0; Gerrit-trigger plugin 2.17.0
I set both ignore commit from certain users and in certain paths. But neither worked.
How do people deal with it when it relates to change version number in certain file and don't want that to trigger a build?
winnerwbx you might consider creating a small test job which does not use the Gerrit-trigger plugin, just to see if you can confirm that you're using the correct syntax for excluding by user name. Once it is functioning in the simple job, then try that same syntax with your job which uses the Gerrit-trigger plugin.
Mark Waite I tested on a small job without Gerrit-trigger plugin. And the result showed that the polling ignores are well functioning. I tested on all three ignore commit options( by user name, by commit message and by file path), they all worked no matter if the "Force polling using workspace" checked or not.
But once added Gerrit-trigger plugin, it didn't work. The job triggers on all commits despite the polling ignore settings.
I believe this is related to JENKINS-25048. The proposed solution and I believe it makes sense is that the external trigger (web hook) triggers a poll not a build. Like that, all the custom rules for users, included/excluded regions would be honored.
Is there another way to do such things ? I'm in the exact same situation, trying to ignore Jenkins own commits due to continuous delivery. I wanted to use exclusions in pipelines because that's the way I did it with regular jenkins jobs, but if there is another way to achieve this goal, it's more than welcome.
I tried to check on GIT_* env variables, but they're not yet accessible.
Des anyone have a workaround ?
I am seeing the same behavior, but I don't have the gerrit-triger plugin installed.
I am attempting to use a post-commit hook to only build on 2 included regions of my repo.
We have the same behavior, but I don't have the gerrit-triger plugin installed.
We use TFS Service Hooks for external SCM polling.
Having the same issue. Also, the "Polling ignores commits in certain paths" feature is not working as well.