Adding VersionStream for gitlab-runner-18.7

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit df85dadfe31bd09f5029e343b00b8656a6255319 for v18.7.0, found 901991dd22896ca37d58f46f8107bafc30fe2384

Build Details

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

Root Cause Analysis 🔍

The git tag v18.7.0 points to a different commit (901991dd22896ca37d58f46f8107bafc30fe2384) than the expected commit hash (df85dadfe31bd09f5029e343b00b8656a6255319) specified in the build configuration. This indicates either the tag was moved/updated in the upstream repository or there's a mismatch in the build configuration's expected commit hash.

---

🔍 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
• Adding VersionStream for gitaly-18.3 #64066

Suggested Changes

File: gitlab-runner-18.7.yaml

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

expected-commit: df85dadfe31bd09f5029e343b00b8656a6255319

Replacement:

expected-commit: 901991dd22896ca37d58f46f8107bafc30fe2384

Content:

Update the expected-commit hash to match the actual commit that tag v18.7.0 points to

Click to expand fix analysis

Analysis

The pattern across all three similar fixes is consistent: when a git checkout fails due to an expected-commit mismatch, the fix is to update the expected-commit hash in the git-checkout step to match the actual commit hash that the tag points to. In all cases, the build files were updated to use the correct commit hash that corresponds to the specified version tag (v18.3.0 in the examples, v18.7.0 in the current case). The fixes show that tags can be moved/updated in upstream repositories, requiring the expected-commit to be updated accordingly.

Click to expand fix explanation

Explanation

The fix should work because the build failure indicates that the git tag v18.7.0 currently points to commit 901991dd22896ca37d58f46f8107bafc30fe2384, not the expected commit df85dadfe31bd09f5029e343b00b8656a6255319. This is a common occurrence in upstream repositories where tags can be moved, updated, or recreated. By updating the expected-commit field to match the actual commit hash that the tag points to, the git-checkout step will succeed. This approach directly addresses the root cause of the mismatch and follows the exact same pattern used successfully in the three similar fixes provided.

Click to expand alternative approaches

Alternative Approaches

• Remove the expected-commit parameter entirely from the git-checkout step, which would allow any commit that the tag points to, but this reduces build reproducibility and security
• Verify with upstream GitLab whether the tag was intentionally moved and if the new commit contains the expected v18.7.0 code before making the change
• Use a specific commit hash instead of a tag reference, but this would require more frequent updates when new versions are released

---

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