> The docker tests will not be run on any PRs that don't touch bin/solr, solr/packaging or solr/docker.
Sounds good, then! On Fri, Sep 18, 2020 at 11:44 PM Anshum Gupta <ans...@anshumgupta.net> wrote: > I like the idea as I really feel Github actions provide a ton of value. > > It doesn't have to be a blocker for all cases but for it to just run would > be great. We don't really lose anything there. > > On Thu, Sep 17, 2020 at 8:56 AM Houston Putman <houstonput...@gmail.com> > wrote: > >> Thought I'd make this a thread instead of a discussion on a single JIRA >> ticket. >> >> Currently we have gradle precommit run on PRs for master, which is very >> useful and gives people confidence in approving PRs. But precommit is >> obviously not the only thing we care about before committing. It would be >> great to run all the tests every time, but clearly that is too expensive. >> >> In SOLR-14856 <https://issues.apache.org/jira/browse/SOLR-14856>, I >> proposed adding a github action to build and test the solr docker image for >> PRs that affected relevant parts of the repo (solr/docker, solr/bin, >> solr/packaging and solr/contrib/prometheus-exporter/bin). Running the >> docker tests currently takes roughly 12 minutes in the github action, which >> would be costly if it ran on every PR. But when running on the small >> percentage of PRs that affect those code paths, I think the benefit >> outweighs the cost. >> >> Beyond just the docker tests, I think we can leverage this ability for >> other features that are limited to certain code paths. For example running >> tests for contrib modules, testing solr/examples, and many of >> the independent lucene modules. The SolrJ tests just ran in 3 minutes >> locally for me, maybe that'd be a good candidate as well. >> >> Anyways I'm sure there are other good candidates out there, but I just >> wanted to start the discussion and hear other opinions before diving any >> deeper. >> > > > -- > Anshum Gupta >
