feat: support signed commits for resource 'github_repository_file'

[wparr-circle]

Resolves #879

---

Before the change?

• Currently github_repository_file modifies files via the github content API. Which means there is limited support for signed commits (ie. anything which supports automatic signing via API). However there is no support for signing using a custom PGP key this way.

After the change?

• Adds support for sensitive variables 'pgp_signing_key' and 'pgp_signing_key_passphrase' which contains an armored PGP private key and an optional passphrase (if the key is locked). This can be used to sign commits when paired with 'use_contents_api = false', where we manipulate a commit and push it to the reference rather than using the contents API to provide a higher level interface.

(note unverified due to github not having public key of the pgp key used in test and author/committer being mismatched).

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[nickfloyd]

Hey @wparr-circle Thanks for the contributions here. Please run lint when you get the chance! It looks like CI is getting hung up on that. Thanks.

[wparr-circle]

Ran against linters now @nickfloyd! Thanks :)

[kfcampbell]

@wparr-circle do you mind explaining more about the below part of your writeup? I'm not sure I understand, sorry.

where we manipulate a commit and push it to the reference rather than using the contents API to provide a higher level interface.

[wparr-circle]

@kfcampbell Sure no problem! Sorry if I wasn't clear.
Current implementation of this resource is utilising the GitHub Contents API.
We get some verified signature support using this like auto sign for bots/github actions.
However, for the use case of GPG based signing - we can't leverage the contents API. Rather we need to manipulate the git tree directly.

Does that help explain?

I left the old contents API way of working as the default behaviour, because of the size of change creeping up.

[marek-karwacki-rdx]

Hi, is there a timeline on this feature? Thanks