epugh opened a new pull request, #1717: URL: https://github.com/apache/solr/pull/1717
https://issues.apache.org/jira/browse/SOLR-16820 Somehow when I edited `solr/CHANGES.txt` I ended up with lots of merge conflicts. I can't get the original PR https://github.com/apache/solr/pull/1688 to update, so starting a new one. <-- @epugh . # Description The previous collection name validation didn't match the validation used in the CreateCollectionAPI, so it was possible to create a collection name (e.g. `foobar-1.2.3`) that wouldn't pass validation at this stage via the `PackageTool` deploy/undeploy commands. # Solution Use the existing `SolrIdentifierValidator::validateCollectionName` method and regex to ensure consistency of collection names going forwards. # Tests **Request for guidance please**: I haven't attached any unit tests to this PR yet. The `PackageTool` at the head of this workflow doesn't have any existing automated tests that I can find - I'm not sure whether to add a very small scope unit test in the `org.apache.solr.packagemanager` package, or whether that's a bit unhelpful compared to something testing the end-to-end behaviour in `org.apache.solr.cli`, which I'm not sure I'm capable of doing at this stage. Alternatively, I can upload screenshots of manually-driven tests on my machine if that's a suitable option? # Concerns / Risks This PR changes the allowed collection names deployed/undeployed by the `PackageTool`. As discussed on the [PR here](https://issues.apache.org/jira/browse/SOLR-16820) and in [the email thread here](https://lists.apache.org/thread/h7hnksgqwxxl7nkwkhn01r6jn8xjkjjs), the change is mostly widening the allowed options, mitigating the risk of backwards-breaking changes. That said, **this change _does_ have one backwards-impacting change, which is collections targeted by deploy/undeploy commands can no longer start with a `-` character.** I don't believe this is a major risk - as mentioned on JIRA/email, the widening element of this PR should be risk free - but I'd like to call out that it's not 100% additive. Going from `[...]*` to `[...]+` in the regex is a repeat of SOLR-9016, but that's pretty incidental here I think. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
