-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 1.537
Jenkins GIT Plugin 2.0
Jenkins Multiple SCM Plugin 0.2
-
Powered by SuggestiMate
Create a Job with a parameter:
branch
In GIT configuration set branch to:
${branch}
or
*/${branch}
This causes polling to keep detecting changes, even when there are none.
Everything is fine when I hardcode branch name like so:
*/master
[JENKINS-20427] Build Parameter variable in branch name causes polling to detect false changes in GIT
This is broken for us too when we upgraded from Git 1.4 to 2.0. I think it's related to this fix:
https://issues.jenkins-ci.org/browse/JENKINS-7411
Our parameterized build was working fine before.
We had to go back to 1.4 to make things work.
I'd suggest that this is not a minor bug, should be much higher.
Based on the testing of JENKINS-20969, this is fixed in git-client-plugin 1.6.2 and git-plugin 2.0.1
It still doesn't work if you specify ** or leave blank job ${branch} parameter
I'll need more information about your configuration (upload a copy of the job definition) and a copy of the git polling log in order to understand why it doesn't work in your case and does work in other cases. Can you upload that information?
Mark,
No problem I can upload my config tell me how do it and from where get it, generally speaking it like JENKINS-20969 I have a build parameter (string parameter) - branch name to build , which is passed to the git "Branches to build" setting. When this parameter is set to *, **, or is empty, the code checkout in last build gets built again and again instead of an updated branches. I have a trigger to poll scm.
What I want from this job is to monitor changes in all branches and also to be run against specified branch defined by build parameter manually. Moreover then this job is trigged by upstream job or manually with branch to build parameter set to * or ** or left blank I want to rebuild all branches.
The config file can be downloaded to your web browser by appending /config.xml to the end of the URL of your Jenkins job. For example, I have a job named "git-client-plugin-multi". I download the job configuration file from http://localhost:8080/git-client-plugin-multi/config.xml . Once you've downloaded, then you can use the "More Actions" -> "Attach Files" operation on the bug report to attach a file.
I believe the bug that a branch name parameter is not correctly handled by polling has already been reported, and is not yet fixed.
I believe that your intended use model will mostly work, except for the assumption that if the build parameter is the wild card it should rebuild all branches. I think that there is no way with the git plugin to force multiple builds of unchanged branches if they've been built before. I may be wrong on that, but I've not found a way to force a rebuild of all branches when the branches had not changed since the last time they were built.
I don't think this is fixed, or else there's been a regression (Jenkins 1.565).
If I have a simple build that uses a BRANCH parameter that defaults to 'master', it will always trigger when notified to look for changes by Stash (via the /git/notifyCommit api), even if there's no changes.
Git polling log looks like this:
Started on Jun 23, 2014 2:01:35 PM Using strategy: Default [poll] Last Built Revision: Revision f22fe57691485df88098480c2e56c4e51a68ad67 (origin/master) using GIT_SSH to set credentials > git ls-remote -h ssh://git@stash.domain.com/project/repository.git ${BRANCH} Done. Took 0.45 sec Changes found
We're not using wildcards, it's just a simple string parameter with a default setting.
Versions:
Jenkins 1.565
Git client plugin 1.9.1
Git plugin 2.2.1
Confirm this is still reproducible on Jenkins 1.570, git 2.2.2, git-client 1.9.1
I've tested just a plain string
${BRANCH}
parameter which defaults to 'develop'
If I push to another branch I see
Started on Jul 1, 2014 1:40:05 PM Using strategy: Default [poll] Last Built Revision: Revision 582ed36314b3df24d849a92065bc2f997bebeb3e (origin/develop) using GIT_SSH to set credentials > git ls-remote -h servicejenkins@vmrepos01:git/mfoMobileClient.git ${BRANCH} Done. Took 0.72 sec Changes found
I am seeing this same behavior after upgrading from 1.1.21 to 2.2.2.
I noticed that the default is now to always use 'Fast remote polling'; in my production environment I have this option turned off. So, I enabled 'Force polling using workspace', and I am now seeing a different message (but the same behavior of false changes being found), as follows:
Started on Jul 14, 2014 1:16:38 PM Polling SCM changes on slave-host-name Using strategy: Default [poll] Last Built Revision: Revision 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f (origin/release_branch) > git rev-parse --is-inside-work-tree Fetching changes from the remote Git repositories > git config remote.origin.url ssh://build@gitserver/git/product.git Fetching upstream changes from ssh://build@gitserver/git/product.git > git --version > git fetch --tags --progress ssh://build@gitserver/git/product.git +refs/heads/*:refs/remotes/origin/* Polling for changes in > git rev-parse "origin/release_branch^{commit}" > git rev-parse "release_branch^{commit}" > git log --full-history --no-abbrev --format=raw -M -m --raw 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f..9f74e3057c7fb30d2c001f886e394d5bea0271a Done. Took 1.8 sec Changes found
It is interesting to me that the '9f74e3' commit ID in that git log command is the commit immediately before the '44bfcc7' commit. I would have expected the parameters to be in the other order.
I ran these two commands on my slave and got the same results:
> git rev-parse "origin/release_branch^
44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f
> git rev-parse "release_branch^{commit}
"
9f74e3057c7fb30d2c001f886e394d5bea0271a
It looks like the local branch is not being updated to match the remote.
Which is not a surprise to me, since behavior in 1.1 was to check out detached, and never even create a local branch.
After some fiddling and testing, I got this to work. I had to delete the local instance of the branch, at which point Jenkins started recognizing changes. So, it appears that using non-fast polling (ie, 'Force polling using workspace') is an effective workaround if you have a build parameter in the branch name.
HOWEVER, if you have a local instance of the branch in the workspace, then non-fast polling seems to always think there are changes, irrespective of whether you have a variable or not. I will do some more testing and submit a bug report if I can get it to reproduce consistently.
I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration:
Started on Jul 17, 2014 10:50:00 AM
Using strategy: Default
[poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master)
> git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch
Done. Took 0.54 sec
No changes
If we disable the parametrized buildand just set 'master' as branch it works.
I've been struggling with the same problem all week.
What I've determined is that the git plugin is either ignoring any variables created in Parameterized Build, or they are not getting passed. However, Parameterized Build can override variables the Git Plugin cares about.
Environment:
- Use separate directories for workspace set to $GIT_BRANCH/src
- Delete workspace & Force Clone
- Git Plugin: 2.2.2
- Git Client Plugin: 1.10
- GitHub API Plugin: 1.55
- GitHub Plugin: 1.90
Test Case 1: Override GIT_BRANCH
If you create a GIT_BRANCH parameter and run a build with garbage text, you can see the github plugin use that text (by the way, overriding GIT_BRANCH is bad, because it will override all of your automatic github push triggers too). This test shows that Parameterized Build at least runs before the git plugin uses its GIT_BRANCH variable.
Test Case 2: Create a new variable "MYBRANCH", specify $MYBRANCH as the branch to build.
If you now run a paramarized build and set this with some garbage (eg. not a real branch), the git clone should fail. But $MYBRANCH is treated as whitespace because it doesn't exist to the git plugin, thus performing default build behavior and building the last branch to get an update.
Test Case 3: Wrap MYBRANCH with curly braces ${MYBRANCH}
No difference
Test Case 4: Put garbage directly into the branch to build path
Type "asdasd" into the branch to build and see the build fail.
I also then added the EnvInject plugin and attempted to set the GIT_BRANCH variable from there, based on another variable's value, to no success.
My conclusion is that the Git plugin is not evaluating any environment variables passed into the branch specifications. This basically means parameterized builds are useless.
Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/git/GitSCM.java
http://jenkins-ci.org/commit/git-plugin/ea62814db213b41b0e8fe99dbca6898aa369da97
Log:
[FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling
Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/hudson/plugins/git/GitSCM.java
http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04
Log:
[FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling
I'm observing the bug again, Jenkins 2.7, Git plugin 2.5.2 (see also JENKINS-29896)
yk4ever can you provide more details on the case where you're seeing the problem?
I can't duplicate the problem on my Jenkins 2.7.1 with Git plugin 2.5.2 and git client plugin 1.19.6.
So, I'm updating the Jenkins config like this:
http://imgur.com/0H945kK
The polling log before the change (extracted from a build, so ends with "changes found", but doesn't have to):
http://pastebin.com/3Mv3HUQd
The polling log after the change:
http://pastebin.com/igztfdwu
...and then it starts to rebuild the same branch 495 it has just built before (not 1205).
So, apparently, the behavior is very different depending on whether you specify BranchSpec directly as "*" or via a variable that should have the value of "*"
@Nicolas De Loof Any updates on this? This is is a major issue for us as sometimes builds fail because of network issue and when we try to rerun, the job picks up some random branch!
puneeth_n, ndeloof is no longer a maintainer of the git plugin. I was unable to duplicate the problem in my most recent attempt. Can you provide step by step instructions which show the failure on an "out of the box" Jenkins installation? Even better is to provide those step by step instructions and a docker image (like a bug verification job as a pull request to my lts-with-plugins docker instance).
Every time I need to guess what a user is doing it is more time that I could have spent helping in other ways (like fixing other bugs, reviewing proposals, etc.)
markewaite Thanks for the response. I have created a seperate JIRA ticket with all details. Here is the link: https://issues.jenkins-ci.org/browse/JENKINS-38406
Let me know in case of more info
I have seen this same issue with the TFS plugin used in Jenkins Multiple SCM plugin 0.5
markewaite- I was finally able to reproduce this issue 100% if you have access to bitbucket.
1. Have Bitbucket repository with at least 10 branches
2. Create a freestyle job and configure it to use the git plugin but connect to a Bitbucket repository at `$BITBUCKET_URL/git/$PROJECT/$REPO.git`
3. Add a parameter called BRANCH and has the default value of **
4. Use that parameter in the `Branches to build` section
5. Add a poll for changes of `* * * * *` so that it will build every minute
6. Add a shell step of something like "echo hello"
7. Run one build
This will then launch a new build for every branch and then once that is done you will see it build every minute seeing changes.
Let me know if that does not work for you because it has worked 2x for me so far.
This is a major issue for people using a cloud build and has been open since 2013.
Is it not possible to use the same solution for polling without wild cards as it is with wild cards?
mkrussel it is not possible to use the same solution without wild cards as with wild cards as far as I know. Pull requests with automated tests that show the problem and include a fix are certainly welcomed.
Not sure if related to JENKINS-19569.