You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Mike Drob <md...@mdrob.com> on 2021/10/13 17:37:16 UTC
Testing docker images during build
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
Re: Testing docker images during build
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <md...@mdrob.com>:
>
>
> > 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 <ds...@apache.org> 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 <ja...@cominvent.com> 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 <md...@mdrob.com>:
>>> >
>>> > 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: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
Re: Testing docker images during build
Posted by Houston Putman <ho...@apache.org>.
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 <ds...@apache.org> 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 <md...@mdrob.com> 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 <ds...@apache.org> 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 <ja...@cominvent.com>
>>> 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 <md...@mdrob.com>:
>>>> >
>>>> > 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: dev-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>>
Re: Testing docker images during build
Posted by David Smiley <ds...@apache.org>.
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 <md...@mdrob.com> 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 <ds...@apache.org> 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 <ja...@cominvent.com>
>> 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 <md...@mdrob.com>:
>>> >
>>> > 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: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>>
Re: Testing docker images during build
Posted by Mike Drob <md...@mdrob.com>.
> 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 <ds...@apache.org> 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 <ja...@cominvent.com> 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 <md...@mdrob.com>:
>> >
>> > 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: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
Re: Testing docker images during build
Posted by David Smiley <ds...@apache.org>.
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 <ja...@cominvent.com> 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 <md...@mdrob.com>:
> >
> > 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Testing docker images during build
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <md...@mdrob.com>:
>
> 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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org