Adding VersionStream for gitaly-18.4

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit 9f674e14fe447f4879b6fcf1fc7db88d249cb411 for v18.4.0, found e0662676eee1db77f0e541c4d599be45b401343c

Build Details

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

Root Cause Analysis 🔍

Git tag v18.4.0 points to a different commit than expected. The build configuration expects commit 9f674e14fe447f4879b6fcf1fc7db88d249cb411 but the actual tag points to commit e0662676eee1db77f0e541c4d599be45b401343c. This indicates either the tag has been moved/updated in the upstream repository, or the build configuration has an outdated 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 gitaly-18.3 #64066

Suggested Changes

File: gitaly-18.4.yaml

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

expected-commit: 9f674e14fe447f4879b6fcf1fc7db88d249cb411

Replacement:

expected-commit: e0662676eee1db77f0e541c4d599be45b401343c

Content:

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

Click to expand fix analysis

Analysis

Looking at the three similar fixed build failures, there's a clear and consistent pattern: all failures were caused by mismatched expected commit hashes in the git-checkout step. In each case, the fix involved updating the expected-commit field in the pipeline to match the actual commit hash that the git tag points to in the upstream repository. The pattern shows that git tags can be moved or updated upstream, requiring the build configuration to be updated with the correct commit hash. All three fixes simply replaced the outdated expected-commit value with the actual commit hash found in the repository.

Click to expand fix explanation

Explanation

This fix should work because the build failure is caused by a mismatch between the expected commit hash and the actual commit hash that the git tag v18.4.0 points to in the upstream repository. The error message clearly indicates that the build system expected commit 9f674e14fe447f4879b6fcf1fc7db88d249cb411 but found e0662676eee1db77f0e541c4d599be45b401343c. By updating the expected-commit field to match the actual commit hash (e0662676eee1db77f0e541c4d599be45b401343c), the git-checkout step will succeed because the verification will pass. This is exactly the same pattern used in all three similar fixes, where updating the expected-commit hash resolved the build failure immediately. The commit hash verification is a security feature to ensure we're building from the expected source code, so updating it to the correct value maintains security while allowing the build to proceed.

Click to expand alternative approaches

Alternative Approaches

• Remove the expected-commit field entirely to disable commit hash verification, though this reduces security assurance
• Use a different git reference like a specific branch or commit directly instead of the tag, but this would require changing the tag field as well
• Investigate if the upstream repository has multiple tags pointing to different commits and use a more specific tag if available

---

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