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	melange
Failure Point	git checkout step for Drupal 11.2.2

Root Cause Analysis 🔍

The build failed because there's a mismatch between the expected Git commit hash (4a1db0db3b144a42daa0887e904f942a55fe5b6b) and the actual commit hash found (965123445745f50c7fc001c72a96650518c267d2) for the tag '11.2.2'. This could be due to the tag being updated in the repository after the package definition was created, or an incorrect commit hash was specified in the package 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
• fontconfig/2.16.1 package update #46365
• Improve Trino package #51354

Suggested Changes

File: drupal-11.yaml

• replace at line 102 (pipeline git-checkout section)
  Original:

      expected-commit: 4a1db0db3b144a42daa0887e904f942a55fe5b6b

Replacement:

      expected-commit: 965123445745f50c7fc001c72a96650518c267d2

Content:

Update the expected-commit hash to match the actual hash for Drupal 11.2.2 tag

• replace at line 110 (pipeline git-checkout section for recommended-project)
  Original:

      expected-commit: 4a1db0db3b144a42daa0887e904f942a55fe5b6b

Replacement:

      expected-commit: 965123445745f50c7fc001c72a96650518c267d2

Content:

Update the expected-commit hash to match the actual hash for the recommended-project repository

Click to expand fix analysis

Analysis

After examining the similar fixed build failures, a clear pattern emerges. In all three cases, the issue was a mismatch between the expected Git commit hash specified in the melange YAML file and the actual commit hash found when checking out the specified tag. The fixes consistently involved updating the "expected-commit" value in the git-checkout step to match the actual commit hash that the tag points to.

This pattern indicates that when a Git tag is updated in the upstream repository or when it points to a tag object instead of directly to a commit, the build system needs to be updated with the correct commit hash. In some cases, like with gitlab-runner, an entirely new package file was created for the new version.

Click to expand fix explanation

Explanation

The build is failing because the Drupal tag 11.2.2 in the Git repository is pointing to commit 965123445745f50c7fc001c72a96650518c267d2, but the melange YAML file is expecting commit 4a1db0db3b144a42daa0887e904f942a55fe5b6b.

This mismatch can occur for several reasons:

1. The tag may have been force-updated in the upstream repository to point to a different commit
2. The tag might be an annotated tag (pointing to a tag object) rather than a lightweight tag (pointing directly to a commit)
3. The wrong commit hash may have been specified in the original package configuration

By updating the expected-commit value to 965123445745f50c7fc001c72a96650518c267d2 in both git-checkout steps, we align the build configuration with the actual state of the upstream repository. The tag is being used correctly, but we need to update our expectation of which commit that tag resolves to.

Note that we need to update both git-checkout steps since they both reference the same version tag. The first one is for the main drupal repository, and the second is for the recommended-project repository. Both should be using the same commit hash if they're referencing the same version tag.

Click to expand alternative approaches

Alternative Approaches

• Instead of just updating the expected commit hash, we could check if there's a specific reason why the tag was updated and potentially evaluate if we should use a different version tag altogether. However, if 11.2.2 is still the desired version, simply updating the commit hash is the most straightforward solution.
• Another approach would be to add a comment explaining why the commit hash was updated, to provide context for future maintainers. This would be helpful if the tag was deliberately force-updated by upstream for a specific reason.
• If this is a recurring issue with this specific repository, we could consider implementing a more dynamic approach that doesn't require hardcoding the commit hash, but this would require more significant changes to the build system and might reduce security guarantees.

---

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