-
Notifications
You must be signed in to change notification settings - Fork 1k
Validate that imported locked revisions did not change after solving #908
Comments
i think we'd ideally like to see not only a notification of the change, but also a reason why the change occurred. that's information that we can extract from the solver, although it'll probably take some refactoring to get at it. |
That would be great, but would be best in a separate issue/PR, as we really need this ... yesterday 😀 , and the identification part isn't as difficult/involved as refactoring. |
Following the discussion golang#1070 (comment) "Agreed, dep cannot currently be trusted to not make changes after the importers are run. The issue which tracks that is golang#908.", it is clear that the maintainers of the tool do not see it as a reliable project. As such, the users should be correctly informed about the status of the project and what are the goals in order to make it a production ready one.
@carolynvs I was thinking of taking a crack at this over the holiday. Is it still live? |
@Zanadar Yes, I would really appreciate help with this! 💖 It's a high priority item at this point and I will be working on closely related features over holiday as well. If you end up not having time (it is the holidays after all), please let me know as my one of my issues rely on this feature. The change needs to be made here: Line 167 in a926781
We need to warn about any projects where the final revision is different than the original imported revision. This warning only applies to projects that are in both locks, a deleted or new locked project should not print a warning. That function is already looping over the final lock, and we need this logic to happen for every locked project, so don't stuff the logic into the if/else in there. Please feel free to open a PR with whatever you have an ask questions from there. I'll keep an eye for it. |
During import, an importer generates a suggested set of locked revisions based on the locks from the imported config. Then dep solves, and this may end up changing the locked revision. For example, if the revision that they originally locked to no longer exists, or the imported constraint doesn't allow the locked revision.
The
rootAnalyzer
should verify that the imported set of locked revisions matches the final solved locked revisions. If there are any changes, print a warning highlighting the old/new locked revisions. We don't want to fail, because having the config files written to disk as a starting point is still quite useful.The text was updated successfully, but these errors were encountered: