-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Xtext Sign and Deploy process more future proof #2065
Comments
@kthoms @szarnekow @nprediger this is something where i really need help |
When changing to centos-8 the build fails with
|
Working build: https://ci.eclipse.org/xtext/job/releng/job/sign-and-deploy/1535/consoleFull
Failing build: https://ci.eclipse.org/xtext/job/releng/job/sign-and-deploy/1536/consoleFull
|
GPG versions: With GPG 2.2 a new file format was introduced for storuing the GPG keyring. |
https://docs.gradle.org/current/userguide/signing_plugin.html:
|
|
@kthoms yes this is where i was stuck |
We tried a gazillion of permutations. Next step is to disable the GPG magic in the publishing plugin and do this by shell scripting. |
We are thinking to do the Eclipse signing of the jars already within the regular build on the master branch. This would take off more magic from the publishing plugin. |
I assume then we also can’t use gradle to deploy too |
@kthoms @nprediger i have found this one |
@kthoms @nprediger i got this one running |
Try to fix issue: No value has been specified for property 'signatory.keyId'
@nprediger and I are continuing today. Seems that we have some progress now.
|
Try to fix issue: No value has been specified for property 'signatory.keyId'
Based on the work from @cdietrich we have added the GPG credentials to the pipeline. This lead us to the publishing plugin since it then required the possibility to pass the passphrase as parameter. Further it then complained:
We have seen that the property ''signing.gnupg.keyName' should be set to the value of 'signing.keyId'. We did some adjustments on the publishing plugin to handle the additional properties. Further it seems that we have to use |
@cdietrich I think we can close this one? |
yes |
our current sign and deploy process is a big obscure mess nobody who cares anymore understands and that is full of tech. debt
we use a stoneage gradle version and old centos and old java
that worries me a lot.
The text was updated successfully, but these errors were encountered: