Adding VersionStream for gitlab-runner-18.2

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit db60bc83de56fa2bba540cc60524db434612cd02 for v18.2.0, found c24769e865d4fb6da27d512373e2159529abddea

Build Details

Category	Details
Build System	git
Failure Point	git checkout step during Melange build process

Root Cause Analysis 🔍

The git checkout operation failed because the commit hash for tag v18.2.0 did not match the expected commit hash. The build expected commit db60bc83de56fa2bba540cc60524db434612cd02 but found c24769e865d4fb6da27d512373e2159529abddea instead. This indicates either the tag was moved in the upstream repository or there's a mismatch in the package definition.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

• calico-3.29 - usrmerge usr/sbin #44671
• Adding VersionStream for gitlab-kas-17.10 #47613
• Nats box adder #45713

Suggested Changes

File: gitlab-runner-18.2.yaml

• replace at line 33 (pipeline git-checkout section)
  Original:

      expected-commit: db60bc83de56fa2bba540cc60524db434612cd02

Replacement:

      expected-commit: c24769e865d4fb6da27d512373e2159529abddea

Content:

Update the expected-commit hash to match the actual commit hash for the v18.2.0 tag

Click to expand fix analysis

Analysis

Based on the three similar fixed build failures, I observe a common pattern: all involve a mismatch between the expected commit hash and the actual commit hash for a specific git tag. In each case, the fix was to update the expected-commit field in the git-checkout step to match the current commit hash that the tag points to in the upstream repository. This suggests that the tags in these repositories have been moved or updated since the package definition was created. For the current build failure, the same issue appears to be happening - the v18.2.0 tag in the gitlab-runner repository now points to commit c24769e865d4fb6da27d512373e2159529abddea instead of the expected db60bc83de56fa2bba540cc60524db434612cd02.

Click to expand fix explanation

Explanation

The build is failing because the git checkout step is expecting commit hash db60bc83de56fa2bba540cc60524db434612cd02 for tag v18.2.0, but the upstream repository's tag now points to commit c24769e865d4fb6da27d512373e2159529abddea. This mismatch causes the build to fail with the error message FAIL Expected commit db60bc83de56fa2bba540cc60524db434612cd02 for v18.2.0, found c24769e865d4fb6da27d512373e2159529abddea.

The fix is to update the expected-commit hash in the gitlab-runner-18.2.yaml file to match the current commit that the v18.2.0 tag points to in the upstream repository. This approach follows the pattern seen in all three similar fixed build failures where the expected-commit value was updated to match the actual commit hash.

When Git tags in upstream repositories are moved (force-pushed) or updated, which can happen when maintainers make corrections or changes after an initial tag, the commit hash that a tag points to can change. The Melange build system verifies the commit hash as a security measure to ensure the code being built is exactly what was expected. By updating the expected-commit value, we're acknowledging this change and allowing the build to proceed with the current state of the upstream repository.

Click to expand alternative approaches

Alternative Approaches

• Instead of updating the expected-commit, we could pin to a specific commit rather than a tag, but this would deviate from the standard practice in Wolfi and make future updates more complex.
• We could consider implementing a build flag to bypass the expected-commit check in special circumstances, but this would reduce the security guarantees that the expected-commit check provides.
• For frequently changing repositories, we could implement an automated process to regularly check and update the expected-commit hashes in package definitions.

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[OddBloke]

That ci-cve-scan result is a false positive: 18.1 already has an advisory that will be duplicated.