[
https://issues.apache.org/jira/browse/SOLR-15361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15361:
--------------------------------------
Attachment: SOLR-15361.patch
Status: Reopened (was: Reopened)
Ok, first off – i'm uploading a new patch with 2 small tweaks:
* go back to the taskGraph callback approach with a comment explaining why
it's there
** but w/o the inputs.property(key,val) call now that i realize i was just
having a brain fart
* remove the duplicated {{signing}} blocks that Houston noticed
----
{quote}I've tried running this locally, but I get the error:
{quote}
That's ... odd.
A couple of requests to help figure out what you're seeing:
# Did you get prompted at all for a passphrase for your key?
# what does {{gpg --version}} output?
# what does {{gpg2 --version}} output?
# Do you have any 'signing.gnupg' related properties in your
~/.gradle/gradle.properties
# Can you please try using the latest patch, and run the following command
(using your key, not mine) and then attach the files to this jira?
{noformat}
(./gradlew --info clean signDistTar
-Psigning.gnupg.keyName=4DDFABAF68C0F906B76CD9A09C784577F8F58E19; find
solr/packaging/build/) 1>houston.wtf.stdout.txt 2>houston.wtf.stderr.txt
{noformat}
----
Lingering converstaion items w/Dawid...
{quote}inputs.property(key, value) associates a string key-value pair with the
task input state. ..
{quote}
Yep yep, i was just having a brain fart and didn't realize it was just the
single key+val version of input.properties(Map)
{quote}The signing plugin very likely makes the input file an input already
(implicitly) and registers the output as well.
{quote}
yes it does, i was just mistakenly thinking i needed to declare some input for
the failUnlessGpgKeyProperty to ensure it would be included in the taskGraph
even if it had no outputs - i realize now that's completely unneccessary
{quote}I believe this is because once the code of the plugin's extension runs
it reads distribution names and creates the associated scaffolding based on
that. If you change it later on, it won't redo these actions under a new name.
...
{quote}
it's worse then that – it (The signing extension) actually does redo some of
those actions later (when it realizes the distribution has a different
distributionBaseName then it thought during the sequential processing of the
signing block) but that only impacts the name of the files it writes to disk
when the Sign tasks actually execute – in the meantime any other downstream
task trying to "consume" the outputs of those Sign tasks (via dependsOn a
configuration that points at their output) gets the wrong filename – which
never exists, so that downstream task either gets skipped because the (non
existent) file it depends on is up to date, or gets an error trying to use the
(wrong & missing) file if it has other inputs which have changed
> update gradle build to support gpg signing of tgz/zip distributions
> -------------------------------------------------------------------
>
> Key: SOLR-15361
> URL: https://issues.apache.org/jira/browse/SOLR-15361
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Fix For: main (9.0)
>
> Attachments: SOLR-15361.patch, SOLR-15361.patch, SOLR-15361.patch,
> SOLR-15361.patch, SOLR-15361.patch, SOLR-15361.patch
>
>
> the gradle build does not currently have any support for gpg signing the
> distributions we produce.
> this is neccessary for releases, and for being able to "smoke test" our
> Dockerfiles prior to release (by creating mock download servers to confirm
> {{docker build}} can correctly fetch the {{tgz}} & {{tgz.asc}} files we point
> it at)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
