[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281238#comment-17281238
]
Chris M. Hostetter commented on SOLR-15127:
-------------------------------------------
{quote}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)
{quote}
Hmm... i hadn't really thought about it that way – but i was mainly thinking
about it from the "if i build my own image, how do i trust the context i'm
pointing at standpoint" which is very transparent, but i see your point.
{quote}I actually am more in favor of having a strict build from source, than
having the RUN give two separate options.
{quote}
Yeah, I thought it was an interesting idea to "serve two usecases" but I can
appreciate that it can be "too clever to be clear"
{quote}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.
{quote}
Can you give me an example of where/why/how you think it would really matter if
users can't build docker images with local gradle settings?... i feel like the
main usecase where someone might care about that is if they are a java dev who
wants to build a custom (ie: patched) solr image – in which case they can patch
the dockerfile to modify the gradle build command just as easily.
{quote}...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.
{quote}
Agreed: For the "common cases" letting docker build invoke "./gradlew" using
the git repo (either remote URL or local checkout) as the build context seems
like the best of all worlds to me.
I think integration with the build system can be fairly straight forward:
* docker build tasks have no need to "dependsOn" the outputs of any build
tasks, since we aren't going to directly use the outputs of any targets as our
inputs
** we could still potentially dependsOn on other tasks just for "validation"
(ie: don't bother trying to build the docker image if we can't compile source)
but we don't need them
* We *MUST* ensure that no gradle task invoked by the Dockerfile dependsOn
building any solr/docker/build.gradle tasks to ensure no circular loops
** the easiest way to do that is to just keep the docker gradle tasks isolated
and not have _any_ other tasks dependsOn them
** we can also define a special project property (via {{-P}} when Dockerfile
invokes "./gradlew") that the solr/docker/build.gradle tasks check for and
"fail fast" w/an explanation if they see it it set
...I'll work up a new patch.
> 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
