Jan,
Since we are using official docker images for Solr, I think the best place
to upload the RC solr docker images would be to apache/solr-nightly, then
mention that in the RC message.
We should also build the official dockerfile image using the release
candidate binaries and push that instead o
I don't mean to say that testing is needless. The user should be able to
build whatever artifacts without testing if the user chooses.
I think I'm missing the advantage of hooking in tests here in the way you
propose. You refer to "lightweight validation". If the docker tests take
too long then
Smoke tester could test for available docket daemon and just warn if not found.
If found, it will pull and smoke-test docker image too!
Where in the RM process would the docker image be built and pushed?
Jan Høydahl
> 16. okt. 2021 kl. 00:53 skrev Mike Drob :
>
>
> > The way you propose woul
> The way you propose would needlessly delay the build process
I disagree with your characterization as needless here, one could just as
easily say that all tests delay the build process, as well as several other
steps like checksums and signatures for releases.
> A suggestion could be to include
I prefer that we don't do Docker testing in that way; we have an existing
way. The way you propose would needlessly delay the build process.
Perhaps that way might be convenient for those just starting out (who don't
yet have any tests).
~ David Smiley
Apache Lucene/Solr Search Developer
http://w
Multi stage builds are still not allowed in official I believe.
My personal preference is to separate build and test. A suggestion could be to
include a test script in the official image, so folks could invoke a self-test
right after build:
docker run --rm mysolr:mytag selftest.sh
Jan
> 13. o
I've seen some other docker images have a test stage built into the
dockerfile, which makes some sense to me. We could potentially use this in
our builds to add a light-weight validation to the images we produce, I'm
not intending to replace the full suite we have under testDocker -- maybe
that com