Adding an manual release job that applies to release branches publishing maven releases

[yue9944882]

Signed-off-by: yue9944882 291271447@qq.com

@brendandburns i also clarified the usage of the release job in the doc.

#2056 is an example of the generated commits by the job. as the next step, we can cherry-pick this release job to the recent release branches and send a release 11.0.4 for #2041

[brendandburns]

Is there a way that we could use a more official github action for this? I'm a little worried about GPG key exfiltration from a random github action that could get compromised.

[yue9944882]

@brendandburns i didnt find an official action for importing the gpg keys, i tried importing via command lines but it's failing on missing tty device or sth. https://github.com/crazy-max/ghaction-import-gpg this action seems actively maintained and accumulated a few followers. we can switch to official if there is one in the future, what do you think?

[brendandburns]

I don't know. I think I'm super paranoid about supply chain security these days, and handing our signing keys over to a GH action that could get compromised seems like a bad idea.

I will ping the GH people that I know and see if there is a better option. If not we'll see what we can do.

Apologies for the delay!

[brendandburns]

Can you look at this GH Action here:

https://github.com/microsoft/gctoolkit/actions/runs/1604755958/workflow#L32

It appears that you can use the export GPG_TTY=$(tty) line to setup the tty correctly
https://github.com/microsoft/gctoolkit/actions/runs/1604755958/workflow#L42

Let me know if that doesn't work. The Microsoft/GitHub Java folks claim it should work.

Thanks!

[yue9944882]

@brendandburns removed the third-party gpg action. alongside export GPG_TTY=$(tty) i also added --pinentry-mode loopback --passphrase *** to make the --edit-key works. the setup-java action works by editing the settings.xml profile on the worker node but it doesn't directly set up gpg for us.

and in our case, we need to do some additional work editing the key's trust level b/c the key is currently expired. am new to the gpg key renewing process so i stick to the expired key in the release job. we can renew one as a follow-up in the future, after that our release job can be simplified further.

[brendandburns]

One comment about the GPG key handling....

[brendandburns]

Thanks! You can just extend the expiration date for the key, I think, see for example:

https://superuser.com/questions/813421/can-you-extend-the-expiration-date-of-an-already-expired-gpg-key

[brendandburns]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [brendandburns,yue9944882]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment