py3-pydantic/2.11.5 package update

[octo-sts]

[octo-sts]

🔄 Build Failed: Git Checkout Error

FAIL Expected commit d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6 for v2.11.5, found 5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8

Build Details

Category	Details
Build System	git
Failure Point	git checkout

Root Cause Analysis 🔍

The git checkout operation failed because the commit hash associated with tag v2.11.5 (5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8) didn't match the expected commit hash specified in the build configuration (d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6). This suggests either the tag was updated in the repository or there is a mismatch in the build specification.

---

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

Suggested Changes

File: py3-pydantic.yaml

• replace at line 54 (pipeline > git-checkout > expected-commit parameter)
  Original:

      expected-commit: d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6

Replacement:

      expected-commit: 5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8

• replace at line 103 (test > git-checkout > expected-commit parameter)
  Original:

            expected-commit: d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6

Replacement:

            expected-commit: 5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8

Click to expand fix analysis

Analysis

The build failure patterns show a common issue where the expected commit hash in the git-checkout step doesn't match the actual commit hash for the specified tag in the repository. In all three examples, the fix involved updating the expected-commit hash to match the actual commit hash found in the repository for that tag. In some cases, the version was also updated, but the primary fix was always updating the expected-commit value. This mismatch typically happens when a tag is moved or updated in the upstream repository, causing the commit it points to to change from what was previously expected in the build configuration. The error message clearly shows that for tag v2.11.5, the build expects commit d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6 but found commit 5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8 instead.

Click to expand fix explanation

Explanation

The fix updates the expected-commit hash in both places where git-checkout is used in the YAML file. The error message clearly indicates that the expected commit hash (d444cd1cf6c5af54b23a335aff2ea45eaac2c2f6) doesn't match the actual commit hash (5e6d1dc71fe9bd832635cb2e9b4af92286fd00b8) for the tag v2.11.5 in the repository.

This mismatch can happen for several reasons:

1. The tag was moved in the upstream repository (someone force-pushed a change to the tag)
2. The tag points to a tag object rather than directly to a commit, and the hash in the build file referenced the commit instead of the tag object
3. The upstream repository was reorganized

Looking at the upstream changelog, we can see that v2.11.5 includes three fixes related to model rebuilding and field info. It's likely that these changes were finalized after the initial expected-commit hash was added to the YAML file, or the tag was updated to include additional fixes.

By updating the expected-commit hash to match the actual commit hash that the tag points to now, we're telling the build system to accept the current state of the repository for that tag instead of failing because it found a different commit than expected. Both instances of the expected-commit parameter need to be updated since they both reference the same tag and should point to the same commit.

Click to expand alternative approaches

Alternative Approaches

• Instead of manually fixing the expected-commit hash, we could modify the git-checkout step to skip the commit verification by removing the expected-commit field entirely. However, this is not recommended as it removes an important safety check that ensures the code being built is exactly what was intended.
• We could also investigate if there's a way to automatically fetch and verify the commit hash for a given tag before setting the expected-commit value, which would prevent this issue from recurring in the future.
• Another approach would be to use commit hashes instead of tags for more stability, but this would make version updates more complex and is against the general practice of using semantic versioning tags.

---

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