Adding VersionStream for gitlab-kas-18.4

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit 04d831fd6688b49c23904ee6724b86badb381cb0 for v18.4.0, found f88d0abf2a4ac9c4c9dd90f3df45c74ac8d75ed0

Build Details

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

Root Cause Analysis 🔍

The Git tag v18.4.0 points to a different commit than expected. The build system expected commit 04d831fd6688b49c23904ee6724b86badb381cb0 but found f88d0abf2a4ac9c4c9dd90f3df45c74ac8d75ed0. This indicates either the tag was moved/updated in the upstream repository, or there's a mismatch between the expected commit hash in the build configuration and the actual commit the tag points to in the GitLab repository.

---

🔍 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-kas-18.4.yaml

• modification at line 25 (pipeline git-checkout step)
  Original:

expected-commit: 04d831fd6688b49c23904ee6724b86badb381cb0

Replacement:

expected-commit: f88d0abf2a4ac9c4c9dd90f3df45c74ac8d75ed0

Content:

Update the expected-commit hash to match the actual commit that tag v18.4.0 points to in the upstream GitLab repository

Click to expand fix analysis

Analysis

Looking at the three similar fixed build failures, all involve Git checkout operations failing due to mismatched commit hashes for GitLab-related packages (gitlab-pages, gitlab-kas-fips, and gitaly). The consistent pattern across all fixes is updating the expected-commit field in the git-checkout pipeline step to match the actual commit hash that the tag points to in the upstream repository. In each case, the fix involved changing the expected-commit value from the old/incorrect hash to the new/correct hash that the tag actually references. This is a straightforward commit hash update without any other structural changes to the YAML files.

Click to expand fix explanation

Explanation

This fix directly addresses the root cause of the build failure. The error indicates that tag v18.4.0 in the upstream GitLab repository points to commit f88d0abf2a4ac9c4c9dd90f3df45c74ac8d75ed0, but the build configuration expects commit 04d831fd6688b49c23904ee6724b86badb381cb0. This mismatch is typical when upstream repositories update or move tags, which is common in GitLab's release process. By updating the expected-commit field to match the actual commit hash that the tag references, the git-checkout step will succeed and the build can proceed. This approach is consistent with all three similar fixes provided, where the solution was simply updating the expected-commit hash to the correct value found in the upstream repository.

Click to expand alternative approaches

Alternative Approaches

• Remove the expected-commit field entirely to allow any commit that the tag points to, though this reduces build reproducibility and security
• Verify the tag change in the upstream repository first to ensure it's legitimate before updating the commit hash
• Pin to a specific commit hash instead of using the tag, though this would require updating the repository URL and checkout method

---

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