Adding VersionStream for gitlab-pages-18.1

[octo-sts]

No description provided.

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit 1dc7d70039ec13dcbd2911e7e3dcc4778fa55a00 for v18.1.0, found d9bb6fbddfee0f65a28dc3b7389f02e5332bdc2f

Build Details

Category	Details
Build System	git
Failure Point	git checkout --quiet origin/tags/v18.1.0

Root Cause Analysis 🔍

There's a mismatch between the expected commit hash (1dc7d70039ec13dcbd2911e7e3dcc4778fa55a00) and the actual commit hash (d9bb6fbddfee0f65a28dc3b7389f02e5332bdc2f) for tag v18.1.0. This could be due to the tag being moved in the upstream repository, or an incorrect expected commit hash specified in the build configuration.

---

🔍 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-runner-17.11 #51032
• Adding VersionStream for gitlab-kas-17.10 #47613
• Nats box adder #45713

Suggested Changes

File: gitlab-pages-18.1.yaml

• replace at line 29-30 (git-checkout section)
  Original:

      expected-commit: 1dc7d70039ec13dcbd2911e7e3dcc4778fa55a00

Replacement:

      expected-commit: d9bb6fbddfee0f65a28dc3b7389f02e5332bdc2f

Click to expand fix analysis

Analysis

The pattern across the similar fixes is clear: in all three cases, the expected commit hash in the git-checkout step didn't match the actual commit hash for the specified tag. The solution in each case was to update the expected-commit hash in the Melange YAML file to match the actual commit hash found in the upstream repository. This mismatch typically occurs when upstream tags are moved or when commits are cherry-picked after tag creation. None of the fixes involved changing the version number or the tag being checked out - only updating the expected commit hash to match reality.

Click to expand fix explanation

Explanation

The current build failure occurs because the git checkout step expects commit 1dc7d70039ec13dcbd2911e7e3dcc4778fa55a00 for tag v18.1.0, but the actual commit in the upstream repository is d9bb6fbddfee0f65a28dc3b7389f02e5332bdc2f. This mismatch is likely due to the upstream repository having updated the tag after the Melange YAML file was initially created.

The suggested fix updates the expected-commit hash to match the actual commit hash found in the upstream repository for the v18.1.0 tag. This will allow the git-checkout step to complete successfully, as it will now correctly expect the commit hash that actually exists in the repository.

This is the standard approach for fixing this type of issue as demonstrated in all three similar fixes provided. In each case, the solution was to update the expected-commit value to match the actual commit hash in the upstream repository, without changing the version number or tag being checked out.

Click to expand alternative approaches

Alternative Approaches

• Instead of directly updating the expected-commit hash, you could create a new file for the next patch version (e.g., gitlab-pages-18.1.1.yaml) with the correct commit hash. However, this would only be appropriate if there was actually a new upstream release.
• If this is a recurring issue with this repository, you could consider adding a verification step in the pipeline that fetches the actual commit hash for the tag and compares it with the expected one, providing a clearer error message for future occurrences.

---

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