Loki: Fix version info issue that shows wrong version (#7669, #8055)

[HwangTaehyun]

What this PR does / why we need it:

• It should fetch all tags before extracting tag info to ldflag of the build.

  • This issue could happen if a build tag like v2.7.1 was not fetched properly and then the build process was running.

  • The following promtail is https://github.com/grafana/loki/releases/download/v2.7.1/promtail-darwin-arm64.zip

    

  • If there's no tag on the exact commit to publish, then BRANCH variable becomes HEAD, so the VERSION variable becomes like "HEAD-e0af1cc".

    • loki/tools/image-tag

      Lines 7 to 21 in 86dcc82

      	WIP=$(git diff --quiet || echo '-WIP')
      	BRANCH=$(git rev-parse --abbrev-ref HEAD | sed 's#/#-#g')
      	# When 7 chars are not enough to be unique, git automatically uses more.
      	# We are forcing to 7 here, as we are doing for grafana/grafana as well.
      	SHA=$(git rev-parse --short=7 HEAD | head -c7)
      	# If not a tag, use branch-hash else use tag
      	TAG=$((git describe --exact-match 2> /dev/null || echo "") | sed 's/v//g')
      	if [ -z "$TAG" ]
      	then
      	echo "${BRANCH}"-"${SHA}""${WIP}"
      	else
      	echo "${TAG}"
      	fi

    • loki/Makefile

      Line 35 in 86dcc82

      IMAGE_TAG := $(shell ./tools/image-tag)

Which issue(s) this PR fixes:

• Fixes loki 2.7 wrong version information #7669, loki and promtail binaries do not report semver version anymore (all platforms) #8055

Special notes for your reviewer:

• This can happen when the version tag was not fetched properly before the build process.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• CHANGELOG.md updated
• Changes that require user attention or interaction to upgrade are documented in docs/sources/upgrading/_index.md

[CLAassistant]

All committers have signed the CLA.

[grafanabot]

./tools/diff_coverage.sh ../loki-target-branch/test_results.txt test_results.txt ingester,distributor,querier,querier/queryrange,iter,storage,chunkenc,logql,loki

Change in test coverage per package. Green indicates 0 or positive change, red indicates that test coverage for a package fell.

+           ingester	0%
+        distributor	0%
+            querier	0%
+ querier/queryrange	0%
+               iter	0%
+            storage	0%
+           chunkenc	0%
+              logql	0%
+               loki	0%

[MichelHollands]

LGTM. Thanks for this contribution

[MichelHollands]

@HwangTaehyun Thanks for this contribution. Can you rebase and make sure the script has the executable bit set?

[HwangTaehyun]

@MichelHollands Yeah, I rebased and pushed now. And I already set the executable bit to the fetch-tags script!

[grafanabot]

./tools/diff_coverage.sh ../loki-target-branch/test_results.txt test_results.txt ingester,distributor,querier,querier/queryrange,iter,storage,chunkenc,logql,loki

Change in test coverage per package. Green indicates 0 or positive change, red indicates that test coverage for a package fell.

+           ingester	0%
+        distributor	0%
+            querier	0%
+ querier/queryrange	0%
+               iter	0%
+            storage	0%
+           chunkenc	0%
+              logql	0%
+               loki	0%

[chaudum]

@MichelHollands Can you make sure this change is backported to the release-2.7.x branch. Unfortunately it's too late for the 2.7.2 release (which happened yesterday), but there may be another 2.7.x release, who knows.

[grafanabot]

Hello @MichelHollands!
Backport pull requests need to be either:

• Pull requests which address bugs,
• Urgent fixes which need product approval, in order to get merged,
• Docs changes.

Please, if the current pull request addresses a bug fix, label it with the type/bug label.
If it already has the product approval, please add the product-approved label. For docs changes, please add the type/docs label.
If none of the above applies, please consider removing the backport label and target the next major/minor release.
Thanks!

[HwangTaehyun]

@chaudum @MichelHollands Can I know precisely how publishing works is done? Actually, it does not happen if the publisher checkouts the release tag (like 2.7.1) and runs the build script. However, it seems that the publisher checkout to release commit and runs the build script.

[chaudum]

@chaudum @MichelHollands Can I know precisely how publishing works is done? Actually, it does not happen if the publisher checkouts the release tag (like 2.7.1) and runs the build script. However, it seems that the publisher checkout to release commit and runs the build script.

The building and publishing of the binaries happens as a DroneCI step that is triggered upon creating a tag.
Here is an example from the run triggered by the 2.7.2 release.
The pipeline stage does check out the tag, but it did not fetch all tags. It worked for the Docker image build steps, because they call git fetch --tags explicitly, see https://github.com/grafana/loki/blob/main/.drone/drone.yml#L289-L294

[HwangTaehyun]

@chaudum lol, That's what I want to see! Thank you!