-
Notifications
You must be signed in to change notification settings - Fork 28
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
yarn classic: Offline mirror collision #786
Conversation
Based on the commit message (and a missing issue) it is difficult to understand why we're trying to provide a hotfix for a problem that at first glance appears to be a project configuration error, so I'd suggest creating an issue first with all the necessary context and a reproducer to shed more light on this PR since the commit message also hints at a genuine bug in our tool. |
I changed the logic completely by disabling exception raise only for two identical registry packages. That should not be a problem in my opinion. I would finish this problem here and now, rather than just create a temporary solution with a promise of a proper fix in the future. |
Heavy +1 to this! I'll have a look some time this week (earlier rather than later). |
So, just to clarify my understanding, I'll paste an example when processing kiali. The
We're assuming it is safe because we realize it is exactly the same tarball, source url and hash included. Even if we had a Github tarball, for example, we would still verify all the details to assume this "collison" was safe (that is, we are downloading the exact tarball from the same place twice). IIUIC, this solution LGTM. I'd just expand the docstring of the function to make this behavior clear, I'll certainly forget it soon 😅 |
Added more descriptive docstring. |
/re-test |
/retest |
Replace the previous duplicate tarball check with a more accurate collision detection mechanism. The new implementation verifies that all packages mapped to the same tarball name in the offline mirror are actually identical. The previous Counter-based approach only checked for duplicate filenames without validating package equivalence. The new defaultdict-based solution properly detects cases where different packages would overwrite each other's tarballs in the mirror. Update test cases to cover valid duplicate scenarios (identical packages) and invalid collisions (different packages with same tarball name). Signed-off-by: Michal Šoltis <[email protected]>
1c4c6ea
Maintainers will complete the following section
Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:
/ok-to-test
(as is the standard for Pipelines as Code)