[ 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