ruby-3.4/3.4.5 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit a38531fd3f617bf734ef7d6c595325f69985ea1d for v3_4_5, found 20cda200d3ce092571d0b5d342dadca69636cb0f

Build Details

Category	Details
Build System	git
Failure Point	git checkout of Ruby source code

Root Cause Analysis 🔍

The git checkout step failed because the commit hash expected for tag v3_4_5 (a38531fd3f617bf734ef7d6c595325f69985ea1d) does not match the actual commit hash found in the repository (20cda200d3ce092571d0b5d342dadca69636cb0f). This indicates that either the expected commit hash in the build configuration is incorrect or the tag points to a different commit than expected.

---

🔍 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
• calico-3.29 - usrmerge usr/sbin #44671
• scons/4.9.1 package update #48416

Suggested Changes

File: ruby-3.4.yaml

• replacement at line pipeline section, git-checkout step (expected-commit parameter in git-checkout step)
  Original:

expected-commit: a38531fd3f617bf734ef7d6c595325f69985ea1d

Replacement:

expected-commit: 20cda200d3ce092571d0b5d342dadca69636cb0f

Content:

The error message indicates that tag v3_4_5 actually points to commit 20cda200d3ce092571d0b5d342dadca69636cb0f instead of the expected a38531fd3f617bf734ef7d6c595325f69985ea1d

Click to expand fix analysis

Analysis

After examining the similar fixed build failures, I've identified a common pattern: the expected commit hash in the git-checkout step doesn't match the actual commit hash for the specified tag in the repository. This typically happens because Git tags can point to different types of objects (commit object or tag object), and sometimes a tag points to a tag object which then points to a commit object. When tags are updated or force-pushed in the upstream repository, the commit they point to can change. In all three examples, the fix was to update the expected-commit value to match the actual commit hash that the tag currently points to in the repository.

Click to expand fix explanation

Explanation

The build is failing because the git-checkout step is looking for a specific commit hash (a38531fd3f617bf734ef7d6c595325f69985ea1d) when checking out the v3_4_5 tag, but the tag actually points to a different commit (20cda200d3ce092571d0b5d342dadca69636cb0f). This mismatch is causing the build to fail.

This situation likely occurred because the upstream Ruby repository may have changed what commit the v3_4_5 tag points to. This can happen when tags are moved or force-updated in the upstream repository. The Melange build system enforces this commit hash check to ensure reproducibility and to prevent unexpected changes when building packages.

The fix is straightforward: update the expected-commit parameter in the git-checkout step to match the actual commit hash that the v3_4_5 tag currently points to. This allows the build to proceed with the current state of the repository while maintaining the version-specific build.

This approach was successfully used in all three of the example fixes where similar issues occurred with GitLab Runner, Calico, and SCons packages.

Click to expand alternative approaches

Alternative Approaches

• An alternative approach would be to verify the source code by downloading a tarball with a known hash instead of using git-checkout. This would involve modifying the pipeline to use the 'fetch' action with an expected-sha256 parameter pointing to the Ruby 3.4.5 release tarball. This approach would be less susceptible to upstream tag changes but requires knowing the exact tarball hash.
• Another alternative would be to pin to a specific commit hash instead of a tag, removing the tag parameter entirely from the git-checkout step. This would make the build more reproducible but would require manual updates when moving to new versions rather than relying on the tag-based update mechanism.
• A more comprehensive approach would be to implement a verification step that fetches both the tag and its expected commit, and only fails if the source code content differs materially, rather than just the commit hash. This would be more resilient to benign tag updates but would require more complex pipeline configuration.

---

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