I've seen this question which goes in a similar direction but not quite. The problem there was that the tags were simply not pushed correctly.
I am currently using Jenkins to build my python projects using setuptools_scm
, which basically uses git describe
to get a (more or less) sensible version number, even if not on a tag. The pipeline is defined using a seed job in JobDSL like this (abbreviated to get to the main points):
import BuildProjects
BuildProjects.build_projects.each { def bproject ->
multibranchPipelineJob("tool/${bproject}") {
branchSources {
branchSource {
source {
git {
id('tool_${bproject}')
remote("${BuildProjects.scmBaseLocation}/${bproject}.git")
credentialsId(BuildProjects.scmUser)
traits {
gitBranchDiscovery()
gitTagDiscovery()
cloneOptionTrait {
extension {
shallow(false)
noTags(false)
reference('grmblwrx')
timeout(1)
}
}
}
}
}
}
}
}
}
Some configuration values are taken from BuildProjects
.
When running jenkins, I see that it fetches tags:
> git fetch --tags --progress -- ssh://git@git.my-company.net/tools.git +refs/heads/*:refs/remotes/origin/* # timeout=1
and in fact, I can see the tags when I output them in my Jenkinsfile using an
sh "git tag"
block. But using
sh "git describe --tags"
gives
fatal: No tags can describe '<Commit hash>'.
Try --always, or create some tags.
I read somewhere that this might be due to a sparse checkout: The commits between the tag and the current HEAD might be missing. Upon closer inspection, I found in my logs
> git config core.sparsecheckout # timeout=10
> git checkout -f <Commit hash> # timeout=10
right after the git fetch
line shown above. It seems that somehow my configuration in the JobDSL is not respected. Any ideas?
Since I posted my question, we updated our Jenkins instance and some plugins, especially the git plugin. For some reason, it "simply works" now. I cannot reproduce the old setting without a lot of trouble, so I cannot easily figure out what caused the "fix".