[
https://issues.apache.org/jira/browse/SOLR-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315867#comment-17315867
]
Chris M. Hostetter commented on SOLR-15321:
-------------------------------------------
I'm spinning this out of SOLR-15250 where [~houstonputman] said...
{quote}
Actually we probably want to create a folder (not in the build
directory) that stores it, so that we can commit it when we cut the official
release in Git. Therefore we have somewhere to point to here:
[https://github.com/docker-library/official-images/blob/master/library/solr]
We
would need to remove the folder after upping the branch version (8.8.0 ->
8.8.1-SNAPSHOT). But we do need it in the git history
{quote}
Ok – hold on a minute: it sounds like you are suggesting that after we build
our 'Dockerfile.official' for X.Y.Z (hwoever we build it) it should be
committed into solr.git ... on some branch, somewhere, even if we ultimately
delete / replace that file later.
That seems really sketchy to me?
Based on [tianon's response in
#368|https://github.com/docker-solr/docker-solr/issues/368], it was my
understanding that we would _definitely_ need a *seperate* repo somewhere that
would mimic the current functionality of the github.com/docker-solr/docker-solr
repo: hosting the (generated) official "Dockerfile" of every "supported" tag of
{{_/solr}} for the docker-library build system to fetch.
In my understanding/expectation, the "Dockerfile.official" generated by the RM
for release X.Y.Z (with filled in template values from something like
SOLR-15250) would get voted on as part of the X.Y.Z RC process, and once the
vote passed, that }Dockerfile.official} would then get committed into (either
the existing, or some new apache/ org replacement of the current)
docker-solr.git repo as {{X.Y/Dockerfile}} (exactly like it has in the past,
just generated from a new/diff build & templating process) and the tag
meta-data files used by docker-library would be updated accordingly (exactly
like it has in the past)
Can you please elaborate on how exactly you are envisioning these (generated)
"official" Dockerfiles – for multiple solr versions – will be
committed/managed/lifecycled in the (existing) solr.git repo?
I'm all in favor of not using/needing a separate docker-solr.git repo ... i
just don't understand how that could/would work cleanly with what we have to
provide to docker-library in their system/process
(In poking around the docker-library docs on the manifest files, I sort of
understand how we could use {{GitCommit}} + {{GitFetch}} to point at an
(official) Dockerfile for X.Y.Z that only briefly existed in the solr.git repo
... but that still seems super sketchy, and using our primary repo as the place
we keep (official) Dockerfiles that we expect docker-library to build seems to
violate their best practices)
> 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]
