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 of the local one built with local artifacts. We might need to make an additional gradle artifact to make this possible, but I would have to look around more to be sure. I think this would fit best right after building and uploading the binary RC artifacts, since those will be used to generate the docker image. I'm happy to do this work in the release wizard once we get closer to the release date. Side question, since we are thinking of adding this to the smoke tester, should this be included in whatever generate-artifacts gradle task we have that the smoke test relies on? David & Mike, I think I'm ambivalent about this. I do think that it's a cool use of multi-stage docker images, and it would be nice to ensure the image is correct during the build. I also wouldn't necessarily want to slow down the build too much, because a lot of the time we are iterating on solr code and building images, which likely won't affect the docker tests at all. But there are very specialized use cases where people are building docker images in locations that don't allow running of docker images, so they can build but not test.... Not going to say who, but that situation does exist... So this would obviously be a big win in that scenario. We already have a system of templating the dockerfiles we use, that combine different layers. We could introduce another gradle command *gradle buildVerifiedDocker* or something like that, which basically takes the local dockerfile, adds a test stage after the build, and a final stage to return the original image. This is a lightweight way of allowing users to test during the docker build, without forcing it, and it doesn't require us to maintain multiple docker files. (Thanks hoss, for making this possible) - Houston On Sun, Oct 17, 2021 at 11:55 PM David Smiley <[email protected]> wrote: > 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 couldn't you add a new gradle task that does the bare minimum > test? > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Oct 15, 2021 at 6:53 PM Mike Drob <[email protected]> wrote: > >> > 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] >>>> >>>>
