[
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17907539#comment-17907539
]
David Smiley commented on SOLR-17602:
-------------------------------------
{quote}Similar validation logic exists already in smoke tester (python),
checking for (un)expected content in release artifacts.
{quote}
I briefly looked but didn't notice anything truly comparable to what this PR
proposes. How would it even know what *dependencies* are "expected" or not
without what I propose in this issue, I wonder. Humans needs should review
this during the PR process IMO.
Yeah versions.lock was a pain; I think this text file is better: – no hash, and
it focuses on the release/assembly output, not the global set of dependencies
that may or may not actually be included in the release. In truth I *also*
care about other dependencies albeit less.
The process can be simpler than what I indicate in the description above to
make it even more painless: no task to remember as a human or for dependabot.
We can have the generation task attach to an earlier phase in the gradle
lifecycle that we typically run (TBD which). Then later the validation step
that's attached to "check" will always succeed unless you somehow committed
stuff without running the build and thus running the script.
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
