[
https://issues.apache.org/jira/browse/SOLR-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320575#comment-17320575
]
Houston Putman commented on SOLR-15250:
---------------------------------------
Very disappointing that we can't use the multi-stage builds. I agree that at
this point we either have one file that the "local" and "official" Dockerfiles
are both templated from, or they are just managed independently. I guess this
also crosses-off the discussion on leading ARGs, since those are related to the
multi-stage build.
{quote}I'm fine with embedding the RM's key fingerprint in the Dockerfile since
docker-library seems to want that – but wouldn't it make more sense to download
the KEYS file direct from apache.org (to resolve that fingerprint to usable
key) then to rely on third-party key servers?
{quote}
No disagreement from me.
{quote}Ok ... I thought the important thing was the the (effective) base image
*USED* had to be an official (approved) image ...
{quote}
Yeah, I would definitely love to be able to use those ARGs personally. It seems
like it's just not a feature much of the rest of the community cares about
unfortunately.
So at this point, which option do you prefer [~hossman]?
* One template that is used for both "official" and "local"
** Nice that we can guarantee the important logic is the same
* Two Dockerfiles managed independently?
** Far less complexity in terms of templating. We would just need to find a
way to verify they stay somewhat in-sync.
> Dockerfile for local builds that can also serve as template for 'official'
> docker images
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-15250
> URL: https://issues.apache.org/jira/browse/SOLR-15250
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15250.patch
>
>
> This issue tracks PoC work experimenting with the idea of the following
> workflow:
> For Users:
> * a {{Dockerfile}} (or {{Dockerfile.local}}) in our git repo that can be
> used (directly or via gradle) to build docker images directly from a local
> solr.tgz (in the docker build context)
> For Release Manager:
> * The exact same {{Dockerfile}} serves as a "template" that gradle tasks use
> to generate a {{build/Dockerfile.official}} via some very simple
> substitutions to fill in ARG defaults based on the "official"
> solr-VERSION.tgz for this release
> * This {{Dockerfile.official}} can then be committed to the docker-solr
> github repo (or some similar new 9.x+ repo) and can be build with a a
> completely empty build context – in which it downloads (and validates) the
> official solr-VERSION.tgz (based on the ARG values that were filled in during
> the release)
> * Automated tests can help us "validate" that the generated
> {{Dockerfile.official}} will work _prior_ to officially publishing release
> artifacts, by using a "mock" download server to host the local
> solr-VERSION.tgz file
> The driving goal being that the Dockerfile used for official {{_/solr}}
> builds should be as close as possible to identical to the Dockerfile used for
> "local" builds by users – given the constraints put on us by the
> docker-library team.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
