Jenkins Source Management (GIT) ignoring refspec/branch filters

user_331359 0
Viewed 316

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 -- git@gitlab.com:[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 -- git@gitlab.com:[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

devops jenkins version-control git regex
1 Answers

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.

VonC_63090
Related