Script to go from GitHub repo to WordPress SVN

[joshkoenig]

We need a script for converting this github project to publish via SVN to wp.org/plugins. There are a few already out there, eg:

http://scribu.net/blog/deploying-from-git-to-svn.html

https://danielbachhuber.com/2012/09/30/git-in-my-subversion/

And some tools that could help:

https://github.com/benbalter/WP-Readme-to-Github-Markdown

It would be great to make something that we can share w/others on this. Would be an excellent best-practice to share.

The goal is to have a "scripts" directory in the plugin that includes a shell script to do the translation/release in a repeatable way. We can rely on the local script-running user having all appropriate access credentials.

Bonus Points it would be great to lay out a pattern for doing development work on Pantheon as well, pulling changes from a Pantheon site repo into this repo via git subtree merge. That would be a separate item in the scripts directory.

[joshkoenig]

More prior art to take into account (thx to @afragen for these!)

https://github.com/dd32/Github-to-WordPress-Plugins-Sync

https://github.com/GaryJones/wordpress-plugin-git-flow-svn-deploy

[danielbachhuber]

/me puts on his curmudgeon hat

For a long time now, I've wanted an automated way to deploy to WordPress.org SVN from Github. master branch would automatically sync with trunk, and tagged releases would magically appear as SVN tags. And yet, I still do it manually through the approach documented in my blog post.

As a plugin maintainer, my chief responsibility is to ensure every release is as bug-free as I can make it. Because I haven't come across, or produced, a Git to SVN script I trust to work reliably, I consider it my responsibility to manually produce and verify each release. Furthermore, I've run into race condition problems on Travis which has meant an old, slower build deploys over a newer, already completed build.

The REST API also has a release script which I believe Ryan runs manually https://github.com/WP-API/WP-API/blob/develop/bin/release.sh We could package something similar, although I think it's critically important the maintainer does a final review of the code to be committed.

It would be great to make something that we can share w/others on this. Would be an excellent best-practice to share.

Conceivably, we could put this in WP-CLI too.

[joshkoenig]

I don't disagree that testing and review should be a part of the release process. What I'm looking for is a standard process for doing this so that it's done consistently, and that the repeatable parts of it can be automated.

The goal for me for such a script would be to get master over to trunk, maybe automated. I'd still assume that release tags would be cut by a person, although IMHO that person should probably be using a script rather than operating the VCS tools by hand.

The goal isn't to allow a clueless operator (or bot) to do it; rather the goal is to insure that a consistent process is followed over time, reducing the potential for human error, and eliminating regressions as a result of tinkering.

[danielbachhuber]

Fair enough. I suppose the interface could be bash bin/release-wp-org.sh <plugin-slug> [tag]. It could also do a bit of a pre-flight routine — php lint, verify the stable version has been updated, etc.

[joshkoenig]

@allan23 This one seems like it's actively maintained:

https://github.com/mikejolley/github-to-wordpress-deploy-script

[allan23]

@joshkoenig This works pretty well. I tried it on one of my personal plugins. The only thing it lacks is the ability to remove dev-only files (unit tests, etc.).

But it wouldn't be too difficult to add ignore to the script. Something like:

svn propedit svn:ignore tests
svn propedit svn:ignore examples

Due to the auth key requirement, it isn't something we can add to the repo.

[allan23]

Just had thought: we might be able to use this in Travis CI. Might need some extensive testing for automation, but an idea.

[joshkoenig]

Having CI auto release to wordpress.org when we make a release here would be an ultimate end-goal.

What I want for this release is a consistent release process. I don't believe that exists without a script. ;)

Definitely don't want to have an auth key in the repo. We could make a pull request upstream to have it take auth information from the ENV? That's a pretty standard pattern for bash scripts.

[allan23]

Probably will need to rework the workflow. We ideally don't want every merged PR to be committed to WP.org.

We could setup a 'develop' branch and then when ready for release, merge that into 'master'. From there, maybe we can get the CI to run the script. I know we can set environmental variables in Travis.

[stevector]

@danielbachhuber This issue looks like https://runcommand.io/for/release-plugin-wordpress-org/

[danielbachhuber]

In fact, it does :)

[ataylorme]

This script will need to:

• Compile production assets with Grunt
• Run composer install to download dependencies
• Update trunk in SVN
• Create a new tag in SVN

[stevector]

@davidstrauss, I know you have thoughts on ways to do git -> SVN. Do you have time this afternoon, tomorrow or Wednesday to discuss with @danielbachhuber? Daniel has some availability and could make progress here.

[davidstrauss]

@stevector Any chance the built-in support in git meets the needs? https://git-scm.com/docs/git-svn