[
https://issues.apache.org/jira/browse/SOLR-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15335:
--------------------------------------
Attachment: SOLR-15335.patch
Status: Open (was: Open)
I started working on replacing the SimpleTemplateEngine usage with our own
transformation logic that only supports a special comment syntax, and variable
replacement _only_ if those variables are in FROM or ARG lines.
After writing a very nice and clean java class (inline in the build.gradle
file) implementing {{org.gradle.api.Transformer<String,String>}} in a very
efficient way i banged my head against gradle/groovy and how much it doesn't
seem to want to play nicely with java generics .. and even when I tried to make
my code less nice and less clean I ran into differnet problems because groovy
does not seem to like java lambdas and Matcher.replaceAll doesn't like groovy
closures ... and even when I tried to make a concrete class implement
{{Function<MatchResult,String>}} i was reminded thta groovy doesn't play nicely
with java generics.
So i gave up on the clean+efficient approach (you can see it in nocommit
comments at the bottom of build.gradle in this updated patch if anyone thinks
thye can tame gradle/groovy's assumptions about java generics/labdas) and went
with a less efficient but still kind of clean approach.
I definitely like how much this eliminates hte need to stress out about '$'
characters in the Dockerfiles, so i think this is a better "templating"
approach long term (allthough hopefully we can make the groovy/java code a bit
cleaner)
filling in the SHA checksum should be easy -- i've got that code somewhere in a
recent experiment patch ... the GPG fingerprint will need to wait until we have
release signing tooling in the gradle build files (unless it already exists?
... i can't seem to find it?) ... but in the meantime I'll try to setup a way
to "test the Dockerfile.official" using local mock download servers.
> templated (header + body) approach for building Dockerfile.local +
> Dockerfile.official w/common guts
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-15335
> URL: https://issues.apache.org/jira/browse/SOLR-15335
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15335.patch, SOLR-15335.patch
>
>
> Goals:
> * "generate" a Dockerfile.official at release time that will satisfy the
> process/tooling of docker-library for 'official' docker images
> ** use a templated approach to fill in things like version, sha512, and GPG
> fingerprint
> * ensure that the generated Dockerfile.official and the Dockerfile.local
> included in solr.tgz are identical in terms of the "operational" aspects of a
> Solr docker image (ie: what the disk layout looks like, and how it runs)
> ** they should only differ in how they get the contents of a solr.tgz into
> the docker image (and how much they trust it before unpacking it)
> * minimize the amount of overhead needed to make changes that exist in in
> both dockerfiles
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
