Adding VersionStream for gitlab-runner-18.6

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit bda84871762de5fb1573f4495940e044e8a5a010 for v18.6.0, found 3a847532c33b6fe2a331a651a6f53be1b2ebed79

Build Details

Category	Details
Build System	melange
Failure Point	git checkout step during source code retrieval

Root Cause Analysis 🔍

The git checkout operation failed because the expected commit hash for tag v18.6.0 does not match the actual commit hash found in the repository. This indicates either the tag was moved/updated in the upstream repository, or the expected commit hash in the build configuration is incorrect/outdated.

---

🔍 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

• Adding VersionStream for gitlab-pages-18.3 #64068

Suggested Changes

File: gitlab-runner-18.6.yaml

• update at line around line 25 (pipeline section, git-checkout step)
  Original:

expected-commit: bda84871762de5fb1573f4495940e044e8a5a010

Replacement:

expected-commit: 3a847532c33b6fe2a331a651a6f53be1b2ebed79

Content:

Update the expected-commit hash in the git-checkout step from bda84871762de5fb1573f4495940e044e8a5a010 to 3a847532c33b6fe2a331a651a6f53be1b2ebed79 to match the actual commit hash for tag v18.6.0 in the upstream repository

Click to expand fix analysis

Analysis

All three similar fixes follow an identical pattern: they updated the expected-commit hash in the git-checkout step to match the actual commit hash found in the upstream repository for the same tag version. In each case, the tag (v18.3.0) remained the same, but the expected-commit value was changed from an outdated hash to the correct current hash. This indicates that upstream repositories sometimes update or move tags to point to different commits, requiring the build configuration to be updated with the new commit hash.

Click to expand fix explanation

Explanation

The fix involves updating the expected-commit hash in the git-checkout step to match the actual commit hash found in the upstream repository. The error message clearly indicates that tag v18.6.0 now points to commit 3a847532c33b6fe2a331a651a6f53be1b2ebed79 instead of the expected bda84871762de5fb1573f4495940e044e8a5a010. This is a common occurrence in upstream repositories where tags can be moved or updated. By updating the expected-commit value to the correct hash, the git checkout operation will succeed and the build will proceed normally. This approach maintains the same tag version while aligning with the current state of the upstream repository.

Click to expand alternative approaches

Alternative Approaches

• Remove the expected-commit parameter entirely to allow any commit associated with the tag, though this reduces build reproducibility
• Verify the tag change is intentional by checking upstream release notes or commit history before updating the hash
• Consider pinning to a specific commit hash without using tags if tag stability is a concern

---

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

[OddBloke]

The reported CVEs are false positives (due to version suffix mismatch), and we can't issue an advisory until the package lands.

[aborrero]

LGTM.