Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
360 views
in Technique[技术] by (71.8m points)

regex - Jenkins Source Management (GIT) ignoring refspec/branch filters

I've two main jenkins environment that works off the same repositories but for different releases. A common design as far as I know. The products have a beta and a release state and should be deployed accordingly by automated pipelines on the respective jenkins.

Here is an example of the GIT configuration for the beta version:
branch: */tags/beta/*
refspec: +refs/tags/beta/:refs/remotes/origin/tags/beta/
beta configuration

And here is an example of the GIT configuration for the release version:
branch: */tags/release/*
refspec: +refs/tags/release/:refs/remotes/origin/tags/release/
enter image description here

Problem is, no matter if a tag with name beta/v1.0.1 or release/v1.1.0 is pushed to origin, both the jenkins detect a change and rebuild using simply what seems the latest tag, ignoring the filtering.

Now that I'm thinking about it, this could be relevant. This is the Build Trigger section for both of them. The webhook on the repository is set to trigger on Tag Push only. My expectation was that every tag push is sent to jenkins that then evaluate if it match the filters but apparently it's not the case. enter image description here

I'm fairly new to jenkins so I guess I've misunderstood how this works and would appreciate some guidance, with examples if you have the time.

Run a tag push to get an example of the logs for both the jenkins:

Beta:

11:50:37  > git --version # 'git version 2.20.1'
11:50:37 using GIT_SSH to set credentials 
11:50:37  > git fetch --tags --force --progress -- [email protected]:[OMITTED].git +refs/tags/beta/*:refs/remotes/origin/tags/beta/* # timeout=10
11:50:38  > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:38  > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/betav1.0.14, origin/tags/beta/v1.0.14)
11:50:38  > git config core.sparsecheckout # timeout=10
11:50:38  > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Commit message: "testing"

Release:

11:50:33  > git --version # 'git version 2.20.1'
11:50:33 using GIT_SSH to set credentials Gitlab SSH credentials
11:50:33  > git fetch --tags --force --progress -- [email protected]:[OMITTED].git +refs/tags/*:refs/remotes/origin/tags/release/* # timeout=10
11:50:34  > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:34  > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/beta/v1.0.14, origin/tags/release/beta/v1.0.14)
11:50:34  > git config core.sparsecheckout # timeout=10
11:50:34  > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Commit message: "testing"

Jenkins v2.263.1
The GIT Plugin version are as follows:

GIT Client Plugin 3.6.0  
GIT Parameter Plugin 0.9.13
GIT Plugin 4.5.2

git version

question from:https://stackoverflow.com/questions/65900821/jenkins-source-management-git-ignoring-refspec-branch-filters

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

As suggested in this issue, and illustrated in this issue, I would use as branch specifier:

:origin/tags/beta/*
# or
:origin/tags/release/*

That will force Jenkins to consider changes from origin.

As the OP Claudio in the comments, an issue like:

  • JENKINS-58907 ("Wrong tag determined on commit with multiple tags") suggests that Jenkins (Git plugin) uses the first tag after alphabetically sorting them, which is not accurate.
  • JENKINS-64720 (Git plugin fail to checkout tag) is clearer:

The branch parameter of the git pipeline step does not accept a tag name.
Many other cases are also not supported with the git pipeline step as described in the online help. The checkout step is the preferred Pipeline step for full access to git.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...