[jira] [Commented] (SOLR-15321) Flesh out process for managing/storing "official" Dockerfiles used by docker-library

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

    [ 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: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org