Skip to content
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

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

Draft
wants to merge 9 commits into
base: trunk
Choose a base branch
from

Conversation

dd32
Copy link
Member

@dd32 dd32 commented Jul 5, 2024

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
Copy link
Member Author

dd32 commented Sep 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant