[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280023#comment-17280023
]
Houston Putman commented on SOLR-15127:
---------------------------------------
I think having a conditional RUN in the Dockerfile to support 2 different ways
of building is convenient, but I don't think it makes it very clear for users
to understand where the resulting image comes from. (because it could have been
either of the two code paths)
I do very much agree that having a "build from a remote git url" approach would
be user friendly for users wanting to build images of various points in the git
history. I actually am more in favor of having a strict build from source, than
having the RUN give two separate options. If the build-image was completely
restricted to using gradle, then we could also get the SOLR_VERSION from
gradle. Just add a {{./gradlew solrVersion}} task, or something like that.
While I do think that would be convenient for users trying to build without a
Java environment, it would be a downgrade in usability for local development.
Not being able to use local gradle settings would be unfortunate.
I do agree with your issues in SOLR-15127, regarding not being able to validate
the Solr TGZ context before using it as a context. It is unfortunate that
docker doesn't provide us with the ability to verify TGZs before using the
context, because I do think that the TGZ solution finds the middle ground of
the issues mentioned above.
Sorry I don't have a clear opinion on how to go forward. I think there are
downsides for all 3 options. But for now I think the lowest downside option is:
Build from clean git repo, without the conditional in RUN. We will have to
think of how this integrates with the rest of the gradle build. It will
certainly be interesting.
> All-In-One Dockerfile for building local images as well as reproducible
> release builds directly from (remote) git tags
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-15127
> URL: https://issues.apache.org/jira/browse/SOLR-15127
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15127.patch
>
>
> There was a recent dev@lucene discussion about the future of the
> github/docker-solr repo and (Apache) "official" solr docker images and using
> the "apache/solr" nameing vs (docker-library official) "_/solr" names...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAD4GwrNCPEnAJAjy4tY%3DpMeX5vWvnFyLe9ZDaXmF4J8XchA98Q%40mail.gmail.com%3E
> In that disussion, mak pointed out that docker-library evidently allows for
> some more flexibility in the way "official" docker-library packages can be
> built (compared to the rules that were evidnlty in place when the mak setup
> the current docker-solr image building process/tooling), pointing out how the
> "docker official" elasticsearch images are current built from the "elastic
> official" elasticsearch images...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3C3CED9683-1DD2-4F08-97F9-4FC549EDE47D%40greenhills.co.uk%3E
> Based on this, I proposed that we could probably restructure the Solr
> Dockerfile so that it could be useful for both "local development" -- using
> the current repo checkout -- as well as for "apache official" apache/solr
> images that could be reproducibly built directly from pristine git tags using
> the remote git URL syntax supported by "docker build" (and then -- evidently
> -- extended by trivial one line Dockerfiles for the "docker-library official"
> _/solr images)...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101221423340.16298%40slate%3E
> This jira tracks this idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
