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.