drupal-11/11.2.2 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit 4a1db0db3b144a42daa0887e904f942a55fe5b6b for 11.2.2, found 965123445745f50c7fc001c72a96650518c267d2

Build Details

Category	Details
Build System	git
Failure Point	git checkout --quiet origin/tags/11.2.2

Root Cause Analysis 🔍

The expected commit hash for tag '11.2.2' doesn't match the actual commit hash found in the repository. The build script expected commit '4a1db0db3b144a42daa0887e904f942a55fe5b6b' but found '965123445745f50c7fc001c72a96650518c267d2'. This likely means either the tag was updated in the repository since the package recipe was written, or there's a mismatch in the package definition.

---

🔍 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
• Improve Trino package #51354
• gitlab-runner-17.11/17.11.1 package update #52449

Suggested Changes

File: drupal-11.yaml

• replace at line 55 (pipeline.uses: git-checkout.with.expected-commit)
  Original:

      expected-commit: 4a1db0db3b144a42daa0887e904f942a55fe5b6b

Replacement:

      expected-commit: 965123445745f50c7fc001c72a96650518c267d2

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I can see that all three examples involve the same core issue: a mismatch between the expected Git commit hash in the Melange YAML file and the actual commit hash found when checking out a specific tag.

The pattern in these fixes is consistent:

1. In each case, the expected-commit parameter in the git-checkout step needed to be updated to match the actual commit that the tag points to in the repository.
2. Sometimes this is accompanied by a version update, but not always.
3. None of the fixes involved changing the repository URL or tag name - only the expected commit hash.

This suggests that Git tags can be updated to point to different commits after a package recipe is written, causing builds to fail until the expected commit hash is updated to match reality.

Click to expand fix explanation

Explanation

The build is failing because the expected commit hash for the tag '11.2.2' in the drupal/drupal repository doesn't match the actual commit hash that the tag currently points to in the repository.

The error message clearly states:

FAIL Expected commit 4a1db0db3b144a42daa0887e904f942a55fe5b6b for 11.2.2, found 965123445745f50c7fc001c72a96650518c267d2

This indicates that the tag '11.2.2' now points to commit '965123445745f50c7fc001c72a96650518c267d2' instead of the expected '4a1db0db3b144a42daa0887e904f942a55fe5b6b'.

The solution is straightforward: update the expected-commit value in the git-checkout step to match the actual commit hash that the tag currently points to. This is consistent with the fixes seen in all three examples where the expected commit hash was updated to match the actual commit hash found in the repository.

This kind of mismatch can happen when:

1. A tag is moved to point to a different commit after the package recipe was written
2. The tag itself is a "tag object" rather than directly pointing to a commit (as hinted in some of the error messages)
3. The repository maintainers force-pushed changes that altered the commit history

The fix doesn't require changing the version or any other aspects of the configuration - just updating the expected commit hash to match reality.

Click to expand alternative approaches

Alternative Approaches

• An alternative approach would be to also update the expected commit hash for the 'recommended-project' repository checkout that happens immediately after the main checkout. The current recipe uses the same expected-commit value for both repositories. If both tags have been updated, both expected-commit values might need to be updated. However, since the error only mentions the first checkout, it's best to fix that first and see if a second error occurs.
• Another approach could be to contact the Drupal maintainers to understand why the tag was changed and ensure this is an expected and legitimate change rather than an error or security issue. However, this is more of a follow-up action rather than an immediate fix.

---

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

[debasishbsws]

@AmberArcadia There is no change just te epoch bump. Is it a case where the github api is getting a wrong commit SHA?

[debasishbsws]

maybe need to close this

[AmberArcadia]

Dang, yep, you're right, thanks.