[
https://issues.apache.org/jira/browse/SOLR-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317365#comment-17317365
]
Chris M. Hostetter commented on SOLR-15321:
-------------------------------------------
{quote}So could a hybrid approach work, where we provision a {{solr-docker}}
repo at apache, that only contains final Dockerfiles and scripts in version
folders. Not all the build infrastructure and templating as now (that will be
in main repo and partly gradle).
{quote}
Right, that's what i was understanding we would almost certainly need –
although one thing Houston and i have been talking about is that even the
'scripts' should live in the solr.git repo, and get bundled into the solr.tgz
(that gets "VOTE"ed on during the release) and used as the docker build context
(SOLR-15322).
Ideally the docker-solr.git repo should be *JUST* the per-version Dockerfiles
produced by each release
{quote}2. During release, an "official" docker image is produced and pushed to
e.g. {{apache/solr:9.0.0-STAGING}} used to smoke-test release
{quote}
Nit-pick, but i would suggest these should be {{apache/solr:9.0.0-RC1}}, etc...
{quote}2. Push the Dockerfile to official {{_/solr:9.0.0}} and submit the PR
(may need a slightly different dockerfile?)
{quote}
Strictly speaking we don't get to "push" directly to {{_/solr:9.0.0}}, we only
get to commit the Dockerfile to our docker-solr.git repo, and submit the PR to
the docker-library/official-images.git repo to add the metadata so that _they_
build it.
We *ABSOLTELY* need a different Dockerfile for this this then what we currently
have in solr.git/main – not just slightly. the feedback we've gotten from
docker-library and the various docs/faqs about what are "allowed" make it clear
that the Dockerfile used for {{_/solr}} is going to have to be radically
different from what we have for people who want to run {{./gradlew
dockerBuild}} in terms of how it gets the "bits" of Solr make it into the build
context.
I've started referring to these as "Dockerfile.local" (what people use to build
an image locally from gradle) and "Dockerfile.official" (what we give to
docker-library to build {{_/solr}} ) ... in SOLR-15250 we're talking about how
to try and template-ize them from a common base to minimize variance in how the
images actually function.
One key aspect of this that i feel like we should probably start thinking about
is viewing the "Dockerfile.official" files that we produce as "release
artifacts" -- included in the VOTE, and canonically kept in archive.apache.org.
(Committing them into docker-solr.git after the release is just something we
do to make docker-library happy)
> Flesh out process for managing/storing "official" Dockerfiles used by
> docker-library
> ------------------------------------------------------------------------------------
>
> Key: SOLR-15321
> URL: https://issues.apache.org/jira/browse/SOLR-15321
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Priority: Major
>
> Assuming we (the Apache Solr TLP) do want to be the maintainer of "official"
> {{_/solr}} docker images moving forward, we need to flesh out how/where
> exactly we plan on storing/managing/maintaining the Dockerfiles that should
> be pointed to by the docker-library manifest file for solr...
> [https://github.com/docker-library/official-images/blob/master/library/solr]
> ie:
> * what replaces [https://github.com/docker-solr/docker-solr.git]
> * what process do we use to update/manage this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
