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 <[email protected]>: > > > > 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 a test script in the official image, so > > folks could invoke a self-test right after build: > > I like this suggestion and think it would be useful. I'd say that we can work > it in as part of the smoke tester even, but I'm not sure on our current > stance regarding requiring all developers to have an available docker daemon. > Probably still best to leave it just to those who are interested. > > > Thanks for your inputs, Jan and David! > >> On Fri, Oct 15, 2021 at 8:00 AM David Smiley <[email protected]> wrote: >> 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://www.linkedin.com/in/davidwsmiley >> >> >>> On Fri, Oct 15, 2021 at 4:26 AM Jan Høydahl <[email protected]> wrote: >>> 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. okt. 2021 kl. 19:37 skrev Mike Drob <[email protected]>: >>> > >>> > 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 comes later, but I think that the two test models may be >>> > complementary. >>> > >>> > To illustrate, the dockerfile would be modified to look something like: >>> > >>> > FROM base as build >>> > # Assemble image as normal >>> > ADD ... >>> > RUN ... >>> > >>> > FROM build as test >>> > RUN ./self-test.sh # Or whatever other tests we want >>> > >>> > FROM build as final >>> > >>> > >>> > Do we know if this would be allowed for our official dockerfiles and >>> > images? I remember hearing that multi-stage builds were frowned upon >>> > before, but I don't know the current state of the community right now. >>> > >>> > Are there other concerns with doing things this way? >>> > >>> > Thanks, >>> > Mike >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>>
