[
https://issues.apache.org/jira/browse/LUCENE-10173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated LUCENE-10173:
----------------------------------------
Attachment: LUCENE-10173.patch
Status: Open (was: Open)
[~dawid.weiss]- based on my testing, with both gpg1 and gpg2, using various
configurations, using {{--max-workers 1}} never actually helps address the
problem of getting your passphrase to gpg, because of how the signing plugin
invokes the command – always with "no-tty" + "batch" (and w/gpg1: "use-agent")
that combination seems to guarantee that no matter what your gpg configuration
looks like, you need a non-tty based gpg-agent to handle your passphrase (even
if you use {{--max-workers 1}} )
So the attached patch removes that restriction, and updates the docs a bit to
try and clarify the various things that seemed to have confused you.
I also went ahead and (re-)added an explicit check to that _IF_ the user
specified {{useGpg}} then they must also specify {{signing.gnupg.keyName}}
(prior to your changes i had this in a really ugly taskGraph hack to fail if
any task depended on a "known" task that used the signing plugin – and had a
warning in the docs about the kind of error that might pop up if someone added
a task that used hte signing plugin w/o depending on my special hack – but now
that 'useGpg' is explicitly optional this is much easier to validate)
> remove "--max-workers 1" restriction when using external GPG w/gradle build
> ---------------------------------------------------------------------------
>
> Key: LUCENE-10173
> URL: https://issues.apache.org/jira/browse/LUCENE-10173
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: LUCENE-10173.patch
>
>
> LUCENE-9488 amended the existing support for using gradle's signing plugin
> with external GPG process to sign files, by adding support for the signing
> plugin's java-implementation, and switching to the pure-java implementation
> by default.
> In the process dawid missunderstood some of documented issues that can pop up
> when using an external GPG process, and thought that using an external GPG
> process could _only_ work when using {{--max-workers 1}}.
> As a result, when changing the build so that using an external GPG process
> was _optional_ via 'useGpg' he added an explicit check to fail the build if
> this option is used w/o {{--max-workers 1}}.
> This issue is to:
> * revert that restriction when 'useGpg' is specified since it isn't
> necessary (nor as it turns out, does it actually help)
> * add a new restriction when 'useGpg' is specified to fail fast if the
> required keyName isn't provided (this was handled in a differnet way prior to
> LUCENE-9488, but that logic was removed when 'useGpg' became optional – we
> should add it back if and only if 'useGpg' is specified to prevent a very
> confusing and missleading error message that can occur otherwise)
> * improve the associated docs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
