I believe you were relying on fetching of tags which was implicit in multi-branch pipeline polling with versions of the git plugin prior to release 3.4.0.  Tags are intentionally no longer fetched by default.

Try adding the "Additional Behaviour" for the "Advanced clone options".  Adding that behavior to the multi-branch pipeline will enable fetching of tags, unless you check the checkbox to disable fetching of tags.  It also allows you to use other options if needed (like a reference repository and shallow clone).

stephenc provided a better description in another bug report, but I can't find that other bug report in my JIRA searching.

https://github.com/jenkinsci/git-plugin/pull/528 is probably what you are after if you want to build tags

segdim if you would like to assist with the evaluation of the pull request that stephenconnolly mentioned, you can download the git.hpi and install it on a test system.

Thanks for your response.

I configured my multibranch pipeline in a really simple way (Project repository URL + Discover branches behaviour)

I'm not relying on tags for my build (I don't use them inside my Jenkinsfile). I'm not trying to build tags I just want the Checkout SCM to fetch the last commit from the specified branch.

When I add the "Advanced clone behaviours" and  whether I check or not the "Do not fetch tags" checkbox I get the same result... Jenkins is still trying to run the command with the --tags argument.

git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*

I thought the error was happening during Checkout SCM.

But when I'm looking at the last successful build it looks like the git fetch --tags command is executed before the actual Checkout SCM step.
Here is an extract from the last successful build :

> git rev-parse --is-inside-work-tree # timeout=10
Setting origin to https://git_url/ORG/repo.git
> git config remote.origin.url https://git_url/ORG/repo.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
> git --version # timeout=10
> git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/dev
Seen branch in repository origin/master
Seen branch in repository origin/testing
Seen 3 remote branches
Obtained Jenkinsfile from fc97b4e2eff380cbbc2e45215b45fc9f65b841a0
[Pipeline] node
Running on maître in /opt/jenkins/workspace/repo_dev-OU35GOR6Z36TOQ75SC4PF75S6MDNBWN4ZD5YQCGK3CC3QNMEM4WA
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://git_url/ORG/repo.git
> git init /opt/jenkins/workspace/repo_dev-OU35GOR6Z36TOQ75SC4PF75S6MDNBWN4ZD5YQCGK3CC3QNMEM4WA # timeout=10
Fetching upstream changes from https://git_url/ORG/repo.git
> git --version # timeout=10
> git fetch --no-tags --progress https://git_url/ORG/repo.git +refs/heads/*:refs/remotes/origin/*

Jenkins is running on a Linux platform and our code is also written on Linux. This is happening for all our repositories and we don't use special characters for filenames (only - _ and .)

When I'm executing the same commands ran by Jenkins on the same server I don't have any issue (the tags are properly fetched).

git init test
git config remote.origin.url https://git_url/ORG/repo.git
git fetch --tags --progress origin '+refs/heads/*:refs/remotes/origin/*'

I also tried to create an entire new multibranch pipeline with a different name and I get the same result.

Are you sure that you're running your "outside Jenkins" test in the same locale as you're running inside Jenkins?

The message from command line git seems to indicate it is running in a French locale.  I can't tell if that French locale is UTF-8 aware or if it is an ISO 8859-1 locale.

Is the failure specific to this repository?  For example, can you run a multi-branch pipeline from another repository?

I ran my test on the same server as Jenkins. The locale defined on this server is fr_FR.UTF-8

I deleted the specific tag from the repository and now it works...

This is happening for all our repositories and we don't use special characters for filenames (only - _ and .)

By any chance do you have a shared global library defined? You'll either need the advanced behaviour there too or use the PR I have created and add Discover Tags to the shared library definition

Should be fixed with the current release of the git plugin AIUI

Please reopen if not fixed in current git plugin release

We are using git-client 3.0 and git plugin 4.0. Facing this error intermittently (inside a JNLP node). For cloning we are using a generic LDAP user without password.

And/or please let me know the matching ticket where I can update this issue !!
> GitLab: Your account has been blocked.
fatal: Could not read from remote repository.

On re-try/re-play it works fine.

akmjenkins asking unrelated questions on closed issues is unlikely to get you the help you want. Questions are best asked in the chat channels or on the mailing lists.