[
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've fixed up some mistakes in the Dockerfile.official template, and added
support for actually testing that you can build an image from
Dockerfile.official using mock download servers, and then run our standard bash
tests against that image .... assuming you manually sign the solr.tgz before
you try any of this...
{noformat}
// TODO: HACK for now until the gradle build system knows how to sign
releases.
// Once we have a top level equivilent to 8x's "sign-artifacts" task
for RMs to run,
// it should be 'finalizedBy createDockerfileOfficial' and this HACK
should be updated to use whatever property
// "sign-artifacts" uses to identify the key fingerprint.
//
// Until then, the only way to create/build/test Dockerfile.official is:
// ./gradlew clean assemble
// (cd solr/packaging/build/distributions/ && gpg --output
solr-9.0.0-SNAPSHOT.tgz.asc --detach-sign solr-9.0.0-SNAPSHOT.tgz)
// ./gradlew createDockerfileOfficial
-Psolr.rm.gpg.fingerprint=YOUR_GPG_KEY_FINGERPRINT
// ./gradlew testDockerOfficial
rmGPGFingerPrintHACK = {
propertyOrDefault('solr.rm.gpg.fingerprint', { ->
throw new GradleException("For now, you must manually sign solr.tgz and
specify '-Psolr.rm.gpg.fingerprint=YOURKEY' to build/test Dockerfile.official");
})
{noformat}
...independent of that, there are still a few nocommit's i want to think about
/ clean up before committing...
...but I'd appreciate some sanity review in from at least one other person on
the entire way i approached the "Dockerfile generation" before committing.
If we do go this route, then I think the next step would be cleaning up some of
the TODOs in the Dockerfile.official.header.template – notably around switching
to downloading a KEYs file (instead of a 4rd party keyserver) since that (along
with release signing in gradle) would allow us to have a jenkins jobs that
could generate a mock-key it could sign the release with, and then the docker
tests could host that KEYS file as well.
> 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, 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
