-
Bug
-
Resolution: Won't Fix
-
Blocker
-
Jenkins ver. 1.638
GIT plugin ver. 1.19.0
Requirements:
I want one job, to get the source code from GIT repository, make some tests and then push some changes on the same repository.
- This job should be triggered once the source code is changed.
- This job should should work on all the branches.
Job Description:
Source Code Management:
Branches to build: **
Additional Behaviours:
Polling ignores commits from specific users: I have put my name.
Build Triggers:
Using "git notifyCommit" I have added a hook on gitlab to trigger the build on Jenkins.
On "Build Triggers" section, I'm checking "Poll SCM" option.
Add, Commit & Push:
I made the add and the commit using windows batch.
Push: using git publisher, on "Add branches" i have added the name of the repository.
Problem:
The excluded user is not excluded all the time, which some times cause an infinite loop, and sometimes cause a lot of extra unnecessary builds.
After a lot of investigations, i have checked the source code of the plugin, and i have understood the some reasons of the problem:
1) The plugin is depending on the last build revision, to get "From" & "To" revision number, and this generate a problem, because the "From" of the last build could be for another branch, so it will git all the old revisions and sure this revision contains users not listed in the "Excluded users list", thus a new build will be triggered.
2) If there were changes in three branches for example, and 2 branches should be ignored, but the third one should trigger a build, the three branches will be triggered.
These are the problems i have discovered till now, could anyone tell me when these issues will be fixed? we are blocked a month ago on this problem, and no one is answering us.
- depends on
-
JENKINS-32436 Polling SCM results in infinite builds after pushing changes on GITLab repository
-
- Open
-
I don't think those issues will be fixed any time soon. I work on the git plugin and the git client plugin in my personal time, trying my best to carefully advance those two plugins without regressing them.
I think that the use case you're describing is quite different from the use case which the plugin implements. I doubt that the use case you're describing could be implemented without major risks of incompatibility with existing use cases.
You might want to evaluate other alternatives, like one of the multi-branch plugins. I'm currently using a multi-branch plugin that automatically creates and deletes jobs for each branch that matches a pattern specified in the job definition. I'm not sure that will be enough to resolve your use case, but I think it is a more likely chance that you could start with that, and then propose pull requests as necessary to the git plugin to give it the exclude capability you want, but in the context of a multi-branch use case.
I find the automatically created and deleted jobs easier to understand than the git plugin's intermixing of multiple branches into the history of a single job.
If that isn't workable for you, then you could consider paying someone to implement what you're seeking. I'm not available in that way, since my employer won't allow that, but there are probably others who are available. You could approach Cloudbees or Praqma or one of the other companies which provide commercial support for Jenkins, and could negotiate with them to seek the solution for your use case.