[wp-meta] [Making WordPress.org] #5555: Introduce deploy keys for SVN

[Making WordPress.org]

#5555: Introduce deploy keys for SVN
------------------------------+--------------------
 Reporter:  Clorith           |      Owner:  (none)
     Type:  defect            |     Status:  new
 Priority:  normal            |  Milestone:
Component:  Plugin Directory  |   Keywords:
------------------------------+--------------------
 It's been stated many times that the plugins and themes directories are
 not for version control, they are deployment systems, and should only be
 used as such.

 This means developers should be (and are) using other services, like for
 example GitHub, to host their publicly available code (also to comply with
 for example plugin directory guidelines that un-minified sources code
 needs to be freely available).

 The problem here is the tedium of doing those deploy, with a proper
 workflow, you would be developing on GitHub, making a release, tagging it,
 then having to replicate all the code over to SVN. I know this is a
 contentious topic, and not everyone is a fan of automated workflows from
 locations such as GitHub.

 Many folks use GitHub actions to automate this, but that has a drawback:
 You need to supply your WordPress.org username and password as secrets on
 a 3rd party. This also makes for extra steps if someone else takes over
 maintaining your code.

 I don't know if it's possible to add multiple keys to a user, so that
 application password like keys could be added for a user on SVN, and that
 wouldn't solve the problem of maintainer ownership transfers with 3rd
 party systems.

 My thought is therefore, all SVN assets get their own user, with an auto-
 generated key (the key can be revoked to get a new one from within the
 plugin admin screen by anyone with commit access, and a notification being
 sent to all committers if this is done).

 This would allow existing users to keep doing it the way they've always
 done things with their own user if they want, but they, and new plugins,
 could then also use this new user, which would be unique to each plugin.

 A user like `wp-plugin-${plugin-slug}` would likely not exist already in
 the system, and it would then be possible to block registrations of any
 such prefixed usernames as well.

 If we wanted to take it one step further, and make sure that uses of
 GitHub actions (which would be my preferred approach) do not cause issues,
 we could very easily create our own wp-plugin-deploy action, that would
 help authors not make mistakes during releases.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5555>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org