search

WordPress / wordpress.org

WordPress.org Meta, Git-ified. Synced from git://meta.git.wordpress.org/ This repository is just a mirror of the WordPress Meta subversion repository. Please include a link to a pre-existing ticket on https://meta.trac.wordpress.org/ with every pull request.
https://meta.trac.wordpress.org/
109 stars 140 forks source link

Plugin Directory: Add a low-level upload-zip-to-svn api, basis for a github action #343

Open dd32 opened 2 months ago

dd32 commented 2 months ago

This is a work-in-progress, PR'ing it for sharing and future work.

This could be used by https://meta.trac.wordpress.org/ticket/6086 (Allow uploading ZIPs for plugin updates, to reduce friction) and as the underlying low-level basis for https://meta.trac.wordpress.org/ticket/6087 (Provide a GitHub integration).

This includes some things that will need to be changed before it can be used, such as the SVN auth, whether to overwrite trunk, whether those things should be an option or not, etc.

Please note: This PR existing is not a confirmation that it'll be merged anytime soon.

dd32 commented 3 days ago

such as the SVN auth

We now require SVN Passwords for committing, which makes this slightly harder. Unfortunately we can't have multiple SVN passwords.

Options:

  1. Require SVN Password be passed / provided.
  2. Replace the SVN password with a new one during the process of committing it.
  3. Add support for multiple SVN passwords per user, or alternate way to authenticate as a given user.
  4. Commit the plugin not as the user, but rather, by plugin-admin with a "Version 1.2 of plugin-slug, uploaded by uploader-username" commit message.

Perhaps we could use #1 if SVN password is provided, and #4 if not (but user is authenticated with 2FA)?

#2 is potentially not viable, as we don't really want to replace their password and then have an error occur that means it's not reverted back, and #3 requires apache extension modifications or other authentication changes.

As a variant of #4, If we're committing on behalf of the plugin, we could also commit as a plugin-specific user such as plugin:{$plugin_slug}, but I'm not sure that gains any benefits over using the generic plugin-admin user.

whether to overwrite trunk

Yes. This should only be used to release the next version of this plugin. So overwrite trunk & tag it.

whether those things should be an option or not

No. There's no need to have this configurable. We shouldn't expect "older versions" to be uploadable via such an API.

This doesn't replace SVN, this simply augments it.