You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Houston Putman (Jira)" <ji...@apache.org> on 2021/02/02 23:29:00 UTC
[jira] [Commented] (SOLR-15127) All-In-One Dockerfile for building
local images as well as reproducible release builds directly from (remote)
git tags
[ https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277530#comment-17277530 ]
Houston Putman commented on SOLR-15127:
---------------------------------------
I think there are two possible ways of going forward with something that the official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context itself.
** In order to have the Solr TGZ become the docker context, we would merely need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us to use docker build directly with the released artifacts. That way we can compare pros/cons of each approach.
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would be no required ARGs)
** I think we can actually add the version as a file inside the release, and then read it into an env var as a part of RUN.
Then we can sym-link from /opt/solr to /opt/solr-$version, to keep backwards compatibility.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the {{apt-get install}} section. Until then, I don't mind if it's fetched in the actual image or the builder image. Did you move it to the builder so that the final image wouldn't need the GITHUB_URL arg?
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org