Are you using the experimental update center? There was no recent change in tag fetching behavior in any of the full releases, though there may have been a change in the tag fetching behavior in the beta release, since it is now configuring itself by default to only fetch the refspec required for the current repository.

What plugin versions (git plugin and git client plugin) were you running prior to upgrade?

What plugin versions (git plugin and git client plugin) are you running after upgrade?

You can likely resolve the problem by modifying the configured pipeline job definition, or by adding the advanced clone behavior that enables fetching of tags.

You may also want to check if someone modified the multi-branch pipeline job definition by adding the advanced behavior which disables tag fetching.

Thanks for the very quick reply!

Yeah I totally forgot I was using the experimental repository.

> What plugin versions (git plugin and git client plugin) were you running prior to upgrade?

didn't take not of it

> What plugin versions (git plugin and git client plugin) are you running after upgrade?

3.4.0-alpha-4

> You can likely resolve the problem by modifying the configured pipeline job definition, or by adding the advanced clone behavior that enables fetching of tags.

I tried this but it didn't seem to work. I just realised that the verion is a alpha, so I will try to rollback to a stable one and re-try again. 

thanks for the quick reply again! Will update this ticket as soon as I have more info!

nemo83 you're encountering one of the intentionally selected optimizations that are being added with the 3.4.0 git plugin. stephenc has done an excellent job of revising the underlying components to provide a better experience for pipeline setting of SCM plugin options.

He realized while doing that UI improvement that there are several things which bloat the default pipeline workspace repositories unnecessarily.

Fetching too broad a refspec (more branches than are actually requested) increases the data transfer from the remote server, and increases disc use in the workspace. The new default for pipeline jobs will be to use an intentionally narrowed refspec for the branch being requested.

Fetching tags also increases the data transfer from the remote server and increases disc use. I believe the new default for pipeline jobs will be to not clone tags.

Both those settings can be overridden by adding the clone advanced behavior to the pipeline definition. If you have a case where the override is not working, we want to know about it before the release of git plugin 3.4.0.

rolling back to stable plugins fixed the issue. 

Thanks a million!!

Well, the changes now are in stable and caused a bug in our scripts that depend on git describe working.

I can live with --no-tags being the default, but I really think the UI is hard to grasp. There is no hint what adding "Advanced clone behaviours" changes, and the checkboxes rather imply that those are the normal defaults.
More precisely "Do not fetch tags" is deselected, which is the opposite of the default without "Advanced clone behaviours". I don`t know whether other settings are silently changed. 

nolange79 the git plugin 3.4.0 change log lists other behavior changes.

This (and the other behavior changes) are intentional. They benefit users by reducing the amount of data transferred for each branch (honor refspec is now the default for each of the branches).

Yes, I get the intention, but I find the UI counter-intuitive. if I add advanced settings, and none of them is selected then its not hard to assume that nothing is changed from the default and concluded that the advanced settings are some leftovers than can be removed.

It would be better to initialize the advanced settings with the defaults ("Do not fetch tags" being selected), or even better turn the logic around and turn it into "Do fetch tags".

Further, this is a breaking change for some jobs and I did not get any warning before updating.

Slipping a backwards incompatible changes in the fine print under a "Refactoring" changelog item, which, at least for me, implies no behavioural changes, did cost me quite some time lost trying to find out why my git version detection stuff is no longer working all of a sudden after a stable plugin update. I wish this was announced more prominently

Also, any hints as to how I can turn this back on in my "checkout scm" pipeline step?

zaytsev_work: See JENKINS-43507 for a global workaround.

(Add an "Advanced Clone Behaviours" entry in the branch source behaviors. It can also be set at the Organization/Team-level for GitHub/Bitbucket plugins & co. In that case you'll need to request a re-scan so all sub-jobs are reconfigured appropriately.)

PS: I'll note we were also a bit upset by this change as it broke dozens of builds for us and since we didn't end up on the original issue immediately we wasted quite some time attempting to reconfigure the projects via the Jenkinsfiles. It seems Yury indeed found the "best" solution with this approach (though we all seem to agree it isn't exactly nice).

This issue and JENKINS-51638 killed my work week. I never had as much issues after a plugin update...

I'm sorry to hear that hoppej.

I'd love to have additional help with the beta testing of git client plugin 3.0.0 and git plugin 4.0.0. They are available from the experimental update center.

The Jenkins project gets great benefit from people that actively test beta versions before they are released.

markewaite our central jenkins instance does not allow to add branches.scmbranches. i created JENKINS-56517 as the default option should be "git fetch", not "git fetch --tags" and not "git fetch --no-tags". would be glad if you would know a workaround which gives the tags anyway?

rthurner as far as I know, an additional behavior is available which will allow you to fetch tags as part of the multibranch pipeline. The branch build strategy plugin adds more capabilities (like building all tags).

It is an intentional choice to not pull tags by default.

If anyone knows how to add a fetch --tags in pipeline scripts i spend a beer.

I am calling "git fetch" in shell script for working builds...

Hey hoppej, you can try to define your scm like this:

checkout scm: [
    $class: 'GitSCM',
    branches: [[name: "BRANCH_NAME"]],
    userRemoteConfigs: [[credentialsId: "GIT_CREDENTIALS", url: "GIT_REPOSITORY"]]
]

currently we use the following workaround to deal with "push -f" to branches, and it still does not work in 100% of the cases. 

// code placeholder
  checkout([
    $class: 'GitSCM',
    branches: [[name: 'refs/heads/'+env.BRANCH_NAME]],
    extensions: [[$class: 'CloneOption', noTags: false, shallow: false, depth: 0, reference: '']],
    userRemoteConfigs: scm.userRemoteConfigs,
  ])
  sh "git checkout ${env.BRANCH_NAME}"
  sh "git reset --hard origin/${env.BRANCH_NAME}" 

the main challenge is that there are 3 possibilities

• "git fetch" fetches a branch with tags reachable, the ideal default - and jenkins cannot do it at all
• "git fetch --no-tags" fetches a branch without tags
• "git fetch --tags" fetches tags not reachable from the branch, i.e. other branches also