license-finder cannot be published: "version" job fails when extracting version number (flaky)
Summary
The pipeline of the license-finder project fails in a CI job responsible for publishing the Docker image, with an image tag that corresponds to the version. See failed version
job.
This prevents projects maintainers from deploying new versions of license-finder, but it does not affect end users.
The problematic CI job is flaky, and it sometimes passes.
This does NOT affect major
, the CI job responsible for pushing license-finder:3
. Today, this Docker image is the one GitLab uses by default. See CI template.
Further details
This might be introduced in gitlab-org/security-products/analyzers/license-finder@72de4bed.
Looking at the log, it seems that it fails on this particular line:
CI_COMMIT_TAG=$(git tag -l|grep -e 'v\d\+\.\d\+\.\d\+'|sort -V -r|head -n 1)
See https://gitlab.com/gitlab-org/security-products/analyzers/license-finder/-/jobs/1746675913#L121 (failed) versus https://gitlab.com/gitlab-org/security-products/analyzers/license-finder/-/jobs/1746621214#L128 (retried and successful).
The last git tag created before that change was v3.31.4+2, and the corresponding pipeline was successful.
This doesn't seem related to the Docker image.
- At this time, docker:20.10-dind is equivalent to
docker:20.10.11-dind
, published 11 days ago. - docker:20.10.10-dind was published 16 days ago.
- The
version
job failed 3 weeks ago, then it passed after the pipeline was retried.
Steps to reproduce
Create a new pipeline for the license-finder project.
What is the current bug behavior?
The version
job fails.
Relevant logs and/or screenshots
https://gitlab.com/gitlab-org/security-products/analyzers/license-finder/-/jobs/1828081654
Possible fixes
The error seems to originate from this line of .gitlab/deploy.yml:
# Get the first git tag after sorting tags as versions in reverse order
CI_COMMIT_TAG=$(git tag -l|grep -e 'v\d\+\.\d\+\.\d\+'|sort -V -r|head -n 1)
After comparing finished and failed job logs, the only difference is in the first case, the git repo is reinitialized, and in the second one - initialized a new repo.
So pre probable source of this but is that there are no tags to select.
That could be fixed with fetching tags first git fetch --all --tags
.