Jenkins Pipeline checks out without tags

[stewartbryson]

Have you tested with Jenkins Pipeline? Using a multi-branch project, the shorthand checkout SCM task checks out without tags:

> /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url https://github.com/RedPillAnalytics/checkmate.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.com/RedPillAnalytics/checkmate.git
 > /usr/bin/git --version # timeout=10
using GIT_ASKPASS to set credentials Personal Access Account for RedPillAnalyticsBot user at Github.
 > /usr/bin/git fetch --no-tags --progress https://github.com/RedPillAnalytics/checkmate.git +refs/heads/master:refs/remotes/origin/master
Checking out Revision bf33d31fbfdba146c0efbe5bb42c846b083141e0 (master)
Commit message: "testing a checkout scm in Jenkins."
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f bf33d31fbfdba146c0efbe5bb42c846b083141e0
 > /usr/bin/git rev-list 126de79ceff583ed117703310f8ba599626273f9 # timeout=10

[damnhandy]

I see the same thing here. The consequence is that sometimes it create the next version as I would expect (i.e. 1.0.1, 1.0.2, etc..). Some builds end up resetting the version such that if you're on say 1.0.23, Jenkins will start building 1.0.0 again, or even better, some pre-existing version such as 1.0.3 or something like that.

[damnhandy]

For those running into problems with some of the Jenkins pipeline and Git, I was able to around it temporarily by adding the following:

checkout([
    $class: 'GitSCM',
    branches: scm.branches,
    doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
    extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: true]],
    submoduleCfg: [],
    userRemoteConfigs: scm.userRemoteConfigs
])

This isn't for everyone as it needs the following Script approvals:

method hudson.plugins.git.GitSCM getBranches
method hudson.plugins.git.GitSCM getUserRemoteConfigs
method hudson.plugins.git.GitSCM isDoGenerateSubmoduleConfigurations
method hudson.plugins.git.GitSCMBackwardCompatibility getExtensions

That will at least fetch the tags. Given the need for additional script approvals, it's probably sub optimal.

[adamdubiel]

I use it on Bamboo and it has its own quirks described here. From what i understand the problem is that there are no tags fetched by default? Is remote origin attached when Jenkins pulls the repo?

[MarkEWaite]

Multi-branch pipeline jobs (as of git plugin 3.4.0) intentionally use a narrow refspec targeted specifically at the branch being built, and it intentionally does not fetch tags. The change was made because the typical use case for the pipeline job does not benefit from the extra effort to use a broad refspec and to fetch tags.

If you add the additional behavior for "Advanced clone options", it will again enable tags (and allow you to define a reference repository if you'd like to reduce data transfer even further). It will also allow you to choose a shallow clone to further reduce data transfer from the git server to the Jenkins agent.

Refer to the git plugin 3.4.0 changelog for more details.

[estyrke]

@MarkEWaite Under "advanced clone options" there is a (default unchecked) option for "do not fetch tags". Do you mean to say that adding "advanced clone options" with the "do not fetch tags" untouched will enable tag fetching? That is super confusing! I was expecting that adding "advanced clone options" without chaging any settings within would be the exact same thing as not adding it at all. Thanks for the information though!

[MarkEWaite]

Yes @estyrke you understood it correctly. Super confusing is one of the prices we sometimes pay in our effort to retain as much backwards compatibility as we possibly can.

There are behaviors in the git plugin which I consider to be bugs (like the handling of a branch name that starts with a word, has a slash, and ends with a word), but which are intentionally not fixed (and are surrounded by automated tests) so that we preserve behavioral compatibility for users.

This decision to accept a behavioral compatibility change (in this specific case) was made with very careful thought about who we would affect negatively, compared to who would be helped. The "helped" won in this case, with the down side that some users (like me) had to adapt their job definitions to include an additional behavior which was not present previously.

[adamdubiel]

Thank you both for this discussion :) I wonder if any of you could find the time to update Jenkins + axion docs in this file ?

[MarkEWaite]

I submitted #198 in hopes that is what you wanted to be said. I don't know the axion release plugin, so I am not confident in the pull request, but it is a start of phrasing that others may correct if they wish.

[adamdubiel]

I will close this issue as i merged the docs update, thanks!

[saas2813]

@adamdubiel @MarkEWaite This unexpected behaviour needs to be documented very visibly on the multibranch configuration page. Using very large flashing letters is probably to much but I'm not sure. It has cost me several hours of confusion! At least the "Project Repository" and "Discover branches" documentation boxes should mention that there is unexpected, non-standard, behaviour!

[adamdubiel]

I guess you mean Jenkins docs? Not axion-release? :)

[saas2813]

Ouch, sorry. This was the place I found the reference to it, didn't notice it was not a Jenkins project :-( Thanks for the help :-)

[adamdubiel]

No problem :)