gogatekeeper/4.3.0 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit cd308cf8e90fcb5271a7a5e8924f87982b884cb0 for 4.3.0, found 21ca4dbd3f34c9e83de358fbacdd41c68c666e4f

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 actual commit hash (21ca4dbd3f34c9e83de358fbacdd41c68c666e4f) for tag 4.3.0 does not match the expected commit hash (cd308cf8e90fcb5271a7a5e8924f87982b884cb0) specified in the build configuration. This indicates that either the expected commit hash in the build configuration is outdated, or the tag has been moved to point to a different commit.

---

🔍 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

• drupal-11/11.2.4 package update #65239
• drupal-11/11.2.4 package update #65239

Suggested Changes

File: gogatekeeper.yaml

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

expected-commit: cd308cf8e90fcb5271a7a5e8924f87982b884cb0

Replacement:

expected-commit: 21ca4dbd3f34c9e83de358fbacdd41c68c666e4f

Content:

Update the expected-commit hash to match the actual commit that tag 4.3.0 points to

Click to expand fix analysis

Analysis

Looking at the similar fixed build failures, there's a clear pattern: all failures involve git checkout operations where the expected commit hash doesn't match the actual commit hash for a given tag. In all three examples, the fix was to update the expected-commit field in the YAML configuration to match the actual commit hash that the tag points to in the upstream repository. The fixes show that when a tag points to a different commit than expected, the solution is to update the expected-commit value to the correct hash (which was found in the error message as the "found" commit).

Click to expand fix explanation

Explanation

The fix should work because the error message clearly indicates that tag 4.3.0 in the gogatekeeper/gatekeeper repository points to commit 21ca4dbd3f34c9e83de358fbacdd41c68c666e4f, but the YAML configuration expects commit cd308cf8e90fcb5271a7a5e8924f87982b884cb0. This mismatch causes the git checkout operation to fail. By updating the expected-commit field to the actual commit hash (21ca4dbd3f34c9e83de358fbacdd41c68c666e4f), the git-checkout step will succeed because it will find the expected commit matches what the tag actually points to. This follows the same pattern used in all the similar fixes where the expected-commit was updated to match the reality of what the upstream tag points to.

Click to expand alternative approaches

Alternative Approaches

• Remove the expected-commit field entirely if commit hash validation is not strictly required for this package, though this reduces build reproducibility
• Verify the upstream repository to ensure the tag hasn't been maliciously moved, though the changelog suggests this is a legitimate release
• Use a specific commit hash instead of a tag reference if more precise control over the source code is needed

---

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