Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(pip-compile): Correctly report errors when a lock file is unchanged #29363

Merged
merged 2 commits into from
May 31, 2024

Conversation

mbudnek
Copy link
Contributor

@mbudnek mbudnek commented May 30, 2024

Changes

The pip-compile manager can update multiple lock files when a single input file changes, however the manager would short-circuit and return null as soon as a single lock file remained unchanged after being re-compiled.

This was causing two issues:

  1. Updates to a later lock file could be missed. This is fairly unlikely since the manager trys not to re-compile lock files for which the input haven't changed.
  2. Errors in one lock file update could be swallowed if a later lock file update succeeded but made no changes. This scenario was quite likely, especially in the case where one lock file depends on another since the first failure will result in an unchanged upstream lock file.

This removes the short-circuit behavior so that the manager will re-compile all of the lock files that depend on the changed input file no matter what.

Context

Documentation (please check one with an [x])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository
The pip-compile manager can update multiple lock files when a single
input file changes, however the manager would short-circuit and return
null as soon as a single lock file remained unchanged after being
re-compiled.

This was causing two issues:
1. Updates to a later lock file could be missed.  This is fairly
   unlikely since the manager trys not to re-compile lock files for
   which the input haven't changed.
2. Errors in one lock file update could be swolloed if a later lock file
   update succeeded but made no changes.  This scenario was quite
   likely, especially in the case where one lock file depends on another
   since the first failure will result in an unchanged upstream lock
   file.

This removes the short-circuit behavior so that the manager will
re-compile all of the lock files that depend on the changed input file
no matter what.
@rarkins rarkins added this pull request to the merge queue May 31, 2024
Merged via the queue into renovatebot:main with commit 635854e May 31, 2024
37 checks passed
@renovate-release
Copy link
Collaborator

🎉 This PR is included in version 37.382.4 🎉

The release is available on:

Your semantic-release bot 📦🚀

@mbudnek mbudnek deleted the fix/pip-compile-report-errors branch May 31, 2024 13:04
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
3 participants