efs-utils/2.3.2 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

Expected commit 48cd437bc5212809b1ad546293b3c2931ea79caf for v2.3.2, found e9ff0e1596f8ac566063659cda60290339216727

Build Details

Category	Details
Build System	git
Failure Point	git checkout origin/tags/v2.3.2

Root Cause Analysis 🔍

The build process expected a specific commit hash (48cd437bc5212809b1ad546293b3c2931ea79caf) for tag v2.3.2 but found a different commit hash (e9ff0e1596f8ac566063659cda60290339216727) when checking out the repository. This mismatch caused the build to fail as it was likely using an integrity check to ensure the expected source code was being used.

---

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

Suggested Changes

File: efs-utils.yaml

• replacement at line 48-50 (main package pipeline git-checkout section)
  Original:

  expected-commit: e9ff0e1596f8ac566063659cda60290339216727

Replacement:

  expected-commit: 48cd437bc5212809b1ad546293b3c2931ea79caf

• replacement at line 111-113 (subpackage pipeline git-checkout section)
  Original:

  expected-commit: 48cd437bc5212809b1ad546293b3c2931ea79caf

Replacement:

  expected-commit: e9ff0e1596f8ac566063659cda60290339216727

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, it's clear that all of them involve a mismatch between the expected commit hash and the actual commit hash when checking out a git repository at a specific tag. In each case, the fix was to update the expected-commit hash in the Melange YAML file to match the actual commit hash that corresponds to the tag being used.

The pattern is consistent: when the git-checkout step fails with "Expected commit X, found Y", the solution is to update the expected-commit parameter to match the actual commit hash that the tag points to. This is a common issue when tags in git repositories get updated or when annotated tags are used (which point to tag objects rather than directly to commits).

Click to expand fix explanation

Explanation

The build failure occurs because there's a mismatch between the expected and actual commit hashes for the tag v2.3.2 in the efs-utils repository. Looking at the error message and the YAML file, we can see that:

1. In the main package section, the build expects commit e9ff0e1596f8ac566063659cda60290339216727 but the error message indicates the tag actually points to 48cd437bc5212809b1ad546293b3c2931ea79caf.

2. Interestingly, in the subpackage section, the expected commit is 48cd437bc5212809b1ad546293b3c2931ea79caf (which matches what the error message says should be there for the main package).

The solution is to swap these commit hashes so they match the actual commit that each respective git-checkout operation will find. This appears to be a case where the commit hashes were incorrectly swapped between the main package and subpackage sections.

This approach matches the patterns seen in the similar fixed build failures, where the expected-commit parameter was updated to match the actual commit hash that the tag points to in the upstream repository.

Click to expand alternative approaches

Alternative Approaches

• Rather than swapping the commit hashes, you could update both git-checkout operations to use the same tag variant (annotated vs lightweight) and expected-commit hash, ensuring they're consistent throughout the YAML file.
• Alternatively, you could consider using the git fetch --tags --force approach to ensure you're getting the latest version of all tags, though this is less deterministic and not typically used in Wolfi's build system which prioritizes reproducibility.

---

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