Skip to content

Conversation

@anushkamittal20
Copy link
Contributor

No description provided.

Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
@octo-sts octo-sts bot added the bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages. label Jul 7, 2025
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
@anushkamittal20 anushkamittal20 changed the title add font-lohit-telugu add font pkgs Jul 8, 2025
@octo-sts
Copy link
Contributor

octo-sts bot commented Jul 8, 2025

🔄 Build Failed: Git Checkout Error

FAIL Expected commit 806b09b684deaeb6dba667670f965e7d27391a52 for v2.14, found de537a95240e0105546bed58e15b4a61be28cd89

Build Details

Category Details
Build System melange
Failure Point git checkout step with tag v2.14 from https://github.com/stipub/stixfonts.git

Root Cause Analysis 🔍

The git tag v2.14 in the repository points to commit de537a95240e0105546bed58e15b4a61be28cd89, but the package build expected it to point to commit 806b09b684deaeb6dba667670f965e7d27391a52. This mismatch is causing the build to fail as a safety measure to ensure the exact expected source code is 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

Suggested Changes

File: font-stix-otf.yaml

  • replace at line 18 (In the git-checkout section)
    Original:
      expected-commit: 806b09b684deaeb6dba667670f965e7d27391a52

Replacement:

      expected-commit: de537a95240e0105546bed58e15b4a61be28cd89

Content:

Update the expected-commit hash to match the actual commit hash for tag v2.14
Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I notice a consistent pattern: in all cases, the expected commit hash for a specific git tag no longer matches what's in the repository. This happens when tags are moved in git repositories (force-pushed) to point to different commits than previously expected.

In all three examples, the fix involved updating the expected-commit field in the git-checkout step to match the current commit that the tag points to. In some cases, this was also accompanied by a version update, but the core fix was simply ensuring the expected-commit hash matches the actual commit hash that the tag now points to.

The issue with the stixfonts repository is similar - the tag v2.14 is pointing to commit de537a95240e0105546bed58e15b4a61be28cd89, but the build configuration expects it to point to 806b09b684deaeb6dba667670f965e7d27391a52.

Click to expand fix explanation

Explanation

The build is failing because the expected commit hash specified in the YAML file (806b09b684deaeb6dba667670f965e7d27391a52) doesn't match the actual commit hash that the v2.14 tag points to in the repository (de537a95240e0105546bed58e15b4a61be28cd89).

This mismatch causes the git-checkout step to fail as a safety measure. The melange build system is designed to verify that the exact expected source code is being used by checking commit hashes. When these don't match, the build fails to protect against potential security issues or unexpected changes.

Updating the expected-commit hash to match the current commit hash that the tag points to will allow the build to proceed. This approach works because it aligns the build configuration with the current state of the upstream repository. The check exists to ensure reproducible builds and prevent supply chain attacks, but in this case, we need to acknowledge that the upstream tag has changed and update our expectation accordingly.

This is precisely the same approach used in all three example fixes, where the expected-commit value was updated to match the actual commit hash that the corresponding tag pointed to.

Click to expand alternative approaches

Alternative Approaches

  • Instead of updating the expected-commit hash, we could pin to a specific commit hash instead of using a tag. This would make the build more stable but would require manual updates when new versions are released.
  • If the repository allows it, we could fork the repository and maintain our own copy with stable tags, but this adds maintenance overhead and diverges from upstream.
  • We could investigate if there's a specific reason the tag was moved (security fixes, etc.) and ensure those changes are acceptable before updating the expected-commit hash.

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

@octo-sts octo-sts bot added the ai/skip-comment Stop AI from commenting on PR label Jul 8, 2025
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
Signed-off-by: Anushka Mittal <anushka.mittal@chainguard.dev>
@Dentrax Dentrax merged commit df2349f into wolfi-dev:main Jul 9, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai/skip-comment Stop AI from commenting on PR bincapz/pass bincapz/pass Bincapz (aka. malcontent) scan didn't detect any CRITICALs on the scanned packages.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants