ruby-3.3/3.3.9 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit b200bad6cd40d08e9f33b93e1a85c270b337867c for v3_3_9, found f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6

Build Details

Category	Details
Build System	git
Failure Point	git checkout stage during the Melange build process

Root Cause Analysis 🔍

The build expects a specific Git commit hash (b200bad6cd40d08e9f33b93e1a85c270b337867c) for the Ruby v3_3_9 tag, but found a different commit hash (f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6). This mismatch caused the build to fail as the expected commit validation check failed.

---

🔍 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

• zoxide/0.9.7 package update #42096
• add rancher-machine #48624
• calico-3.29 - usrmerge usr/sbin #44671

Suggested Changes

File: ruby-3.3.yaml

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

      expected-commit: b200bad6cd40d08e9f33b93e1a85c270b337867c

Replacement:

      expected-commit: f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6

Click to expand fix analysis

Analysis

The pattern in the similar fixed build failures is clear: in all three examples, the build failed because the expected Git commit hash in the Melange YAML file didn't match the actual commit hash for the specified tag in the repository. This mismatch occurs because the upstream repository's tags may have been updated or moved since the package definition was created.

Each fix involved updating the expected-commit value in the git-checkout section of the Melange YAML file to match the current commit hash that the tag points to. In some cases, this was accompanied by version bumps or epoch updates, but the core fix was always updating the expected commit hash.

Click to expand fix explanation

Explanation

The build is failing because the expected Git commit hash in the Melange YAML file (b200bad6cd40d08e9f33b93e1a85c270b337867c) doesn't match the actual commit hash that the v3_3_9 tag points to in the Ruby repository (f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6).

This mismatch can occur for several reasons:

1. The upstream repository may have moved the tag to a different commit
2. The tag might have been force-updated with new changes
3. The original commit hash might have been incorrectly specified

The error message explicitly states that the build expects commit b200bad6cd40d08e9f33b93e1a85c270b337867c for the v3_3_9 tag, but found f5c772fc7cbe9f5b58d962939fcb1c7e3fb1cfa6. The simplest solution is to update the expected-commit value to match the current commit hash that the tag points to.

The upstream change log confirms that there have been numerous bug fixes between versions, which explains why the commit hash might have changed. By updating the expected-commit value, we're acknowledging these changes and allowing the build to proceed with the current state of the upstream repository.

Click to expand alternative approaches

Alternative Approaches

• We could remove the 'expected-commit' check entirely by removing that line, which would allow the build to proceed with whatever commit the tag points to. However, this would reduce security as the expected-commit check helps ensure that the code being built is what was expected and reviewed.
• Another approach would be to pin to a specific commit instead of using a tag, but this would make future updates more difficult and wouldn't align with Wolfi's principle of keeping packages updated with upstream releases.
• We could fork the upstream repository and maintain our own tagged versions with stable commit hashes, but this adds maintenance overhead and diverges from the upstream source.

---

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