[
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17907323#comment-17907323
]
Jan Høydahl commented on SOLR-17602:
------------------------------------
Similar validation logic exists already in smoke tester (python), checking for
(un)expected content in release artifacts. Your proposal will give added focus
to such changes earlier in the process, which is good.
With our earlier `versions.lock` file I usually reviewed the diff to this file
in a PR to see if there were unexpected changes to (transitive) dependencies.
Not sure if this is still possible with the new version catalog.
One potential disadvantage of checking in such files is that they tend to be an
additional source of merge conflicts. The `versions.lock` file had checksums
making it extra prone to this. But something to have in mind when deciding the
format. Also it adds another step for contributors to remember before
submitting a PR. And it proved hard to have dependabot generate `versions.lock`
in PRs, so it may be as hard to have it generate this file, and thus fail
precommit?
> Maintain final JAR dependencies in source control to track changes
> ------------------------------------------------------------------
>
> Key: SOLR-17602
> URL: https://issues.apache.org/jira/browse/SOLR-17602
> Project: Solr
> Issue Type: Task
> Components: Build
> Reporter: David Smiley
> Priority: Major
>
> When we make changes to Solr's dependencies (add/remove/change), we edit our
> build files, and the code review process shows these changes to corresponding
> build files. However, what we all *really* want to know is the impact the
> change has on the artifacts our users consume. Almost nobody validates the
> impact; we hope for the best and find out of problems long later.
> This issue tracks one artifact: Solr's final assembly (any of the zip,
> tar.gz, or Docker). I propose committing to source control a machine
> generated file listing of the dependencies in a text file. This file shall
> be updated based on executing a gradle task TBD. When gradle "check" is run,
> it will henceforth ensure that this file hasn't been modified or doesn't
> match the output of the script's generation (details TBD).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
