History of blood and tears
Recently, I encountered a very strange problem when using Jenkins to pull the Git project to compile the code : Jenkins's GitPlugin download code version is wrong (commitId is wrong). Since the compiled product of online deployment and offline deployment are the same version, the code version finally released to the production environment is incorrect. This problem was finally discovered during the online verification phase. Looking back at the entire job construction process, the console did not report an error, and the online package was successfully compiled. So what went wrong?
Initial positioning
At first, I suspected that it was a residual problem of the local Git project , so I tried to delete the WORKSPACE directory on the machine node where the jenkins corresponding job was running to ensure that the latest code can be pulled next time the Jenkins build is triggered.
Delete method:
1. Log in to the machine where the job is running (check the node where the job is running in the console, there is a print on the first line ).
2. Check $WORKSPACE (check in the job console; if you can't find it, add a line of echo $WORKSPACE to the shell executor, and re-execute the job)
3. Delete the corresponding WORKSPACE information. Please operate with caution , first see if the value of WORKSPACE is correct (echo $WORKSPACE), don't make a mistake and delete the root directory! ! ! .
[ -d "$WORKSPACE" ] && rm -rf ${WORKSPACE}
4. Re-trigger job after deletion
After doing this, the final packaged compiled product still has the wrong version.
Since it is not a local code caching problem, is it possible that the version is wrong when GIt pulls the code?
Second troubleshooting
Open the job configuration details on Jenkins, I only filled in " */qa " in BranchSpecifier , my expectation is to match the qa branch in the git specific project (Repository URL) .
Then look at the record of the previous build that had a problem (open the job details page of the current build), and click Git Build Data (on the left):
Two remote branches are shown here. I only configured one qa branch in GitPlugin . There should be only one branch called qa being downloaded. How come there are two branches?
I began to suspect that it might be a rule matching problem with BranchName in the configuration of Git Plugin, which caused two branches to be matched here (one is called qa and the other is called origin/qa).
Open the configuration of the corresponding job on Jenkins again, we see that "*/qa" is filled in BranchSpecifier, * is a wildcard, will there be exactly two branches in this project, as shown in the figure above (origin/qa And qa), exactly matches */qa?
Thinking about it this way, it made sense, so I clicked the question mark on the right side of the Branches Specifier column to view the help, and I could see the help information.
Detailed analysis
//The following sentence means: if you do not fill in the branch specifier (leave it blank or write any), then any branch will be matched, that is, which branch you cannot use in the project. This is generally not recommended.
Specify the branches if you'd like to track a specific branch in a repository. If left blank, all branches will be examined for changes and built.
//The following sentence means: The safest way is to use the syntax of refs/heads/<branchName>
The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch is unambiguous.
//If your branch contains'/' (for example, origin/qa ), it is best to use the syntax mentioned above: refs/heads/<branchName>
If your branch name has a / in it make sure to use the full reference above. When not presented with a full path the plugin will only use the part of the string right of the last slash. Meaning foo/bar will actually match bar.
If you use a wildcard branch specifier, with a slash (e.g. release/), you'll need to specify the origin repository in the branch names to make sure changes are picked up. So e.g. origin/release/
Possible options:
<branchName> //branchName is just a wildcard. For example, realese can match the release branch, or it may match the origin/release. Generally, don’t write this (otherwise you will step on the same pit like me)
//Because of the ambiguity in specifying <branchName>, it is recommended to use refs/heads/<branchName> to clearly specify a specific remote branch.
Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. Better use refs/heads/<branchName>.
E.g. master, feature1,...
refs/heads/<branchName>
Tracks/checks out the specified branch. //checkout a remote branch
E.g. refs/heads/master, refs/heads/feature1/master,...
<remoteRepoName>/<branchName>
Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one.
Better use refs/heads/<branchName>. //This method of specifying remote specific branches may be ambiguous. It is recommended to use refs/heads/<branchName>
E.g. origin/master
remotes/<remoteRepoName>/<branchName>
Tracks/checks out the specified branch. //This way of specifying is also more accurate.
E.g. remotes/origin/master
refs/remotes/<remoteRepoName>/<branchName>
Tracks/checks out the specified branch.
Eg refs/remotes/origin/master //tag specified by checkout, in fact, tagName here will not be regarded as a tag, so it is not recommended to write it.
<tagName>
This does not work since the tag will not be recognized as tag.
Use refs/tags/<tagName> instead. .. //checkout the specified tag, this is the correct syntax.
Eg git-2.3.0
refs/tags/<tagName>
Tracks/checks out the specified tag.
E.g. refs/tags/git-2.3.0
<commitId>
Checks out the specified commit. //checkout指定的commitid
E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
${ENV_VARIABLE}
It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.
E.g. ${TREEISH}, refs/tags/${TAGNAME},...
<Wildcards>
The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard, and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.
:<regular expression>
The syntax is of the form: :regexp. Regular expression syntax in branches to build will only build those branches whose names match the regular expression.
Examples:
:^(?!(origin/prefix)).*
matches: origin or origin/master or origin/feature
does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
:origin/release-\d{8}
matches: origin/release-20150101
does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
:^(?!origin/master$|origin/develop$).*
matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
does not match: origin/master or origin/develop
So when you want to specify a specific branch for pulling, the best four unambiguous writing methods are:
refs/heads/<branchName>
refs/remotes/<remoteRepoName>/<branchName>
refs/tags/<tagName>
<commitId>
The basic problem here is the truth. I went to gitlab and looked at the branch list of this project, and found that there is really a branch called origin/qa. After confirmation with other colleagues, someone created this origin/qa with shaking hands. Branch.
I put the original * / qa replaced refs / Heads / qa , so precisely matched to the specific branch. Try to trigger the job build again. This time the downloaded Git code version is also correct.
This article is an original history of stepping on the pit. If it is helpful to you, please leave me a like, thank you!
Blogger: Test to make money
Motto: Complete the original accumulation through a test career, and move towards financial freedom through investment
csdn：https://blog.csdn.net/ccgshigao
Blog Park: https://www.cnblogs.com/qa-freeroad/