Provide a GitHub Integration for Plugins

[dd32]

Many developers use GitHub to develop their plugins, and only use SVN as a deployment destination.

In order to "modernise" the plugin developer experience, being able to document a GitHub workflow along side the SVN flow, that doesn't require a user to share their WordPress.org password with GitHub or another 3rd-party service would be beneficial.

There's an existing GitHub Action which simply commits to SVN, ​https://github.com/10up/action-wordpress-plugin-deploy but that requires storing the committers password on GitHub, which not all are comfortable doing.

I'm not sure how this would be best implemented, there's multiple options:

• Sync a plugin release on GitHub to plugins.svn automatically
• Treat the GitHub location as the primary source, and pull directly from there with no plugins.svn integration
• Provide a GitHub action that worked with a token and and API from #6086 to upload a release ZIP

Then there's also how to implement it:

• Manual GitHub Action configuration required by the plugin author
• GitHub App to install to the Repo, oAuth's against GitHub and W.org to authorize itself, and takes care of spawning actions as needed
• GitHub App that installs the GitHub action, sets the token, and then doesn't do anything further.

I'm marking this as low priority as there exists an existing GHA for this that works, and there's likely other steps that would need to be done first to allow it (ie. Ability to oAuth against the dotorg account, or for an API to upload via to exist, etc).

[dd32]

See Also: #3880 #3937

[seebeen]

GitHub App to install to the Repo, oAuth's against GitHub and W.org to authorize itself, and takes care of spawning actions as needed

As someone who releases composer modules to packagist.org, a flow similar to theirs would be awesome.
WP.org could either pull the release asset (zip file) or use gitattributes to sync up to github.

[JeffPaul]

but that requires storing the committers password on GitHub, which not all are comfortable doing.

(note I added the emphasis above)

The password is stored as a ​GitHub secret and can be done at an org-level and maintained there and not within individual repos (for folks who maintain multiple plugins within a single org). From GitHub's emphasis on their secrets:

Encrypted secrets allow you to store sensitive information in your organization, repository, or repository environments.

So I'm really not sure that there is a worthwhile solution that won't take a significant amount of time to craft that would be more secure than the current approach. I won't argue that a different approach would be more graceful or seamless an integration, but speaking as someone currently supporting the GitHub Action of note I'm happy to keep triaging and supporting folks using it to keep GitHub and SVN working in tandem (barring overly complex GitHub setups).

[dd32]

Replying to seebeen:

As someone who releases composer modules to packagist.org, a flow similar to theirs would be awesome.
WP.org could either pull the release asset (zip file) or use gitattributes to sync up to github.

As someone who doesn't release composer modules, would my assumption that it simply polls Github for new Releases and pulls the Release / Revision / etc from there be correct?

[dd32]

Replying to JeffPaul:

but that requires storing the committers password on GitHub, which not all are comfortable doing.

(note I added the emphasis above)

The password is stored as a GitHub secret and can be done at an org-level and maintained there and not within individual repos (for folks who maintain multiple plugins within a single org).

To be clear - If someone wanted to do that, that's fine, but WordPress.org can't really say "Share your password with a 3rd party company".. nor can we just expect everyone to be comfortable doing that. It also makes things more complicated for those who change passwords often or use a Password manager.

It would be better if an Application Password could be used at least, so that the auth token is specific to it's use-case and can be revoked or not allowed to be used for login.. ​but our auth extension for SVN is not exactly super flexible, and I'm hesitant to be the one to write the extensions to it needed and end up as the forever maintainer..

There's been cases in the past where PRs against a Github repo have been used to leak Secrets (although these could be seen as mis-configurations) this covers some aspects and even suggests storing scoped tokens: ​https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

I recognise that the existing GHA has had significant investment from 10up in support, development, and ongoing maintenance, but having a native option would be beneficial for all plugin developers and even reviewers.

[JeffPaul]

Totally agree that a native option (especially a straightforward one to setup/maintain per plugin) would be most beneficial. I'd be curious to understand how that would work, as I'd love a more graceful flow.