-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[JENKINS-56063] Fix refSpec with expanded variables on first clone #1013
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ca7e7aa
to
a679141
Compare
a679141
to
a7c26ce
Compare
Tested with the parametrised build plugin and it is working great |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pull request @Sergio-Mira !
I ran the test in the debugger and saw unexpected results at several places. I've offered comments that may help you explore this further.
src/test/java/hudson/plugins/git/extensions/impl/CloneOptionHonorRefSpecTest.java
Outdated
Show resolved
Hide resolved
src/test/java/hudson/plugins/git/extensions/impl/CloneOptionHonorRefSpecTest.java
Outdated
Show resolved
Hide resolved
src/test/java/hudson/plugins/git/extensions/impl/CloneOptionHonorRefSpecTest.java
Outdated
Show resolved
Hide resolved
Checks both system environment variables (like USER on Unix variants and USERNAME on Windows) and Jenkins provided environment variables (like JOB_NAME). Asserts that the variable name does not appear in the build log. Uses a branch based on the value of the variable and asserts that the job is successful. A successful job means that the branch name based on the value of the variable was found and used in the job. Does not assert that the specific commit from the branch is the one that is used in the job. That could be added.
e1b446c
to
3664fda
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the improvements! My apologies for my mistake with JENKINS_USERNAME. That's a local variable on the specific machine where I was running the debugger and I mistakenly assumed it was provided by Jenkins.
Very nice improvements in the parameterized test to remove the extra argument.
src/test/java/hudson/plugins/git/extensions/impl/CloneOptionHonorRefSpecTest.java
Outdated
Show resolved
Hide resolved
src/test/java/hudson/plugins/git/extensions/impl/CloneOptionHonorRefSpecTest.java
Outdated
Show resolved
Hide resolved
src/main/java/hudson/plugins/git/extensions/impl/CloneOption.java
Outdated
Show resolved
Hide resolved
Was returning false even when running on Windows.
Failing on "JOB_BASE_NAME" on CI but not locally, any clues as to why that would happen? Thanks for all the help! |
I suspect that there is something that the randomization is trying to tell us but that I'm not yet understanding. I'm seeing the same CI based failures on my personal CI infrastructure and also am unable to duplicate the failures on either my Windows development computer or my Debian Linux development computer. We may need to remove the randomization and run all the permutations while we try to understand why the tests are failing. The test failures remind me that the failure message is not as helpful as it should be. Complaining that |
0c27aeb
to
3abdd17
Compare
The user expected value in the test is wrong as the user that runs the tests is different to the user of jenkins that builds the test job (with some debugging I saw that on the PR CI its 'jenkins'), will look into a way of getting the real user value, maybe by running a pre-test build first to get those env var values. |
336a8c9
to
ce35838
Compare
Looks like the environment that is getting expanded is taking into account the Jenkins instance that is running the test itself. I can reproduce with JOB_NAME=something mvn test. Will look into fixing it, probably have to change the way the env is obtained for resolving refspec. |
ce35838
to
93b85a0
Compare
@MarkEWaite should be ready for review again, lemme know how it looks. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've run it through a series of tests and sessions in the debugger. There are minor changes to be made after the merge. I'll make those changes with additional commits. Thanks for the fix and for all your effort assuring that the tests work as expected.
List<String> logs = b.getLog(50); | ||
for (String line : logs) { | ||
if (line.startsWith(refSpecName + '=')) { | ||
refSpecExpectedValue = line.split("=")[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkEWaite this seems to be causing a test failure in the BOM, perhaps because there is some environment variable with an empty value: https://github.com/jenkinsci/bom/pull/393/checks?check_run_id=1643221348 (CC @timja)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#1023 applies a fix for that case. I'll try to release a new version of the git plugin with that fix within the next 7 days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Git plugin 4.5.2 released with this fix to the test.
JENKINS-56063 - Fix refSpec with expanded variables on first clone
RefSpecs passed down from build parameters or environments are not being respected on initial checkout, but are on the subsequent ones. This pull request uses the same process used in those subsequent checkouts to resolve the refspecs on the initial checkout.
Checklist
Types of changes
Further comments
Test derived from #830