Cancel

Sarah Gooding

Ship: A New App for Shipping Plugins from GitHub to WordPress.org

One of the small hurdles to hosting a plugin on WordPress.org is the fact that you have to use SVN to ship your updates. Most developers are far more familiar with Git. It’s not difficult to learn how to use SVN for the sake of WordPress.org plugins, but many find it to be inconvenient.

Ship is a new application designed to eliminate this hassle by helping developers ship plugins directly from GitHub to WordPress.org. All you have to do is tag the release on GitHub and the app will automatically push updates to the plugin’s official SVN repo on WordPress.org.

ship

The application was created by Jason Agnew and his team at Big Bite Creative, authors of the Herbert plugin framework. The team built the app in Laravel in just five days. It’s currently hosted on Digital Ocean, but Agnew plans to move it over to AWS once Ship has gained more users.

“We’ve reached a point where most developers are familiar with GitHub, and as a result, Git,” Agnew said in his announcement. “If you plan to do anything open source you’re likely to find yourself on there – even Apple has made the move. Unfortunately WordPress.org uses SVN, which most developers don’t use daily, or are even familiar with. It’s easy enough to pick up, but why should you learn something new to update your plugin?”

With the help of the Ship app, developers won’t have to touch SVN at all during the process of sending updates to WordPress.org plugin repositories.

“For years most plugin developers have used GitHub and then shipped to WordPress.org SVN using a bash script,” Agnew said. “You’ll find plenty out there, but they require you to keep both a Git and SVN repo on your machine — plus you need to remember to run it every time you tag a new release. We thought there must be a simpler way to do this, so we put our heads together. After a few days we had put together the first version of Ship.”

In order to use the app you must have already submitted your plugin zip file to WordPress.org. You can then sign into the Ship app with GitHub and authorize its access to your repositories.

authorize-ship-app

The app will then fetch your repositories and you’ll have the opportunity to select the ones you want to link up with a WordPress.org SVN address in order to start syncing updates.

ship-sync-reops

Big Bite Creative has built many custom plugins over the years, but Agnew said they never had the time to open source them.

“Now with Herbert out there we want to start releasing more plugins on Github – Ship is part of making that process easier,” he said.

In the future, Agnew and his team would like to eliminate the need to first submit your plugin on WordPress.org and instead have that process initiated by Ship. They used “Sign in with GitHub” to save time when initially building the app but would also like to open it up for other services like BitBucket.

The new Ship app effectively gets around WordPress.org’s SVN requirement for plugin repos, which has long been a minor deterrent and annoyance for developers wanting to host their work in the directory. If Ship is successful in making plugin developer’s lives easier, the result will be more open source extensions available to WordPress users. Agnew and his team welcome feedback on the app and have created an empty repo on GiHub to capture any suggestions or issues.

Category: ,
Tags: , ,
58

58 responses to “Ship: A New App for Shipping Plugins from GitHub to WordPress.org”

  2. Ship is a fantastic idea (I haven’t checked the execution yet, although the documentation looks good too). We created a Github to WordPress SVN tool for internal use and it’s made our lives much easier. At some point we may migrate to Ship as it would be one less tool to maintain ourselves.

    Like Timothy, I’m looking forward to hearing more about credentials and security, Sarah.

    Create forum topic from comment
    Reply

  9. My first plugin was approved last week. I must say, SVN was more than a little confusing. Even after reading the docs on the codex, I didn’t understand what I needed to do.

    It was only after reading a blog post written by someone familiar with the whole process was I able to understand it.

    Create forum topic from comment
    Reply

  12. Ditto @modemlooper – I’m a collaborator on other teams repos and they are all bundled into Ship with the sync. That’s not ideal. Awesome tool though and look forward to using this and these items to be cleared up. Good work! :+1:

    Create forum topic from comment
    Reply

      • You are aware that Git has SVn support *built-in*, right? I mean, even if you use Git, you should understand it as a client, and it talks to SVN natively. “git svn clone” and other such things work fine.

        I think the basic problem here isn’t the difference between git and svn, but that people don’t fundamentally understand version control in the first place. Honestly, I blame Github. Github makes people stupid. Yeah, that sounds right. ;)

        Create forum topic from comment
        Reply

        • Oh look, a Git vs. Subversion conversation, how did I miss this! :D

          Github makes people stupid

          I wouldn’t use the word “stupid” but yes, many times too often I hear people saying Subversion doesn’t support pull requests or something like that.

          I’m more concerned with authentication though, passing WordPress.org credentials to a third-party service? No thanks. Over HTTP? No thanks. It’d be much better if they created a central WordPress.org user and asked customers to simply grant them write privileges to their .org repos.

          In that case when there’s a security breach, the WordPress.org team could easily revoke access from that one user, as well as review latest commits to all repos by that one user for malware and stuff, and not search through a subset of god knows how many users.

          Obviously OAuth would be a much better user experience.

          Create forum topic from comment
          Reply

          • Konstantin, I share your concern about login credentials. What would work best here is if WordPress.org built the Github bridge in. There’s little reason for them not to and every reason to do so. I’d guess half the active WordPress developers use Github to collaborate. Perhaps the Ship guys would be happy to contribute their existing code for a nominal fee.

            If not, at Foliovision, we’ve built something similar which we’d be happy to donate as a credited contribution (especially if our senseless WordCamp ban were lifted).

            Create forum topic from comment
            Reply

        • > I think the basic problem here isn’t the difference between git and svn, but that people don’t fundamentally understand version control in the first place. Honestly, I blame Github. Github makes people stupid. Yeah, that sounds right. ;)

          And you find it strange that people are saying that the WP Core Dev team is arrogant and doesn’t listen to its users and slams the door in the faces of people that actually would love to become part of something bigger?

          Really Otto/Samuel this is a great example of how to piss people off. Get off your almighty high horse and get down to earth! Just because you have a few more years of coding under your belt, doesn’t make you better than anyone else.

          There are plenty of developers who fully understand the importance of version control. You just need to learn to accept the fact that there are people around you, breathing the same air as you do that might have a different opinion than you. And if someone says that he/she finds SVN difficult to use, then you don’t have to blame Github for making people stupid. Instead you should try to see it from another perspective.

          Create forum topic from comment
          Reply

          • Shockingly, I didn’t mean that as anything other than a light-hearted jest, but hey, whatever floats your boat, man.

            I deal with a fair number of “new” plugin contributors. Not quite as much as Mika, but still, probably more than you do. For the most part. The thing is, svn really is very easy once you get the right tool. On Windows, I generally recommend Tortoise. On Mac, a lot of people like Cornerstone. On Linux, command line is just there and simple to grasp with 5 minutes of tutorial.

            The thing is, SVN *isn’t hard*. Not like Git, at all. It’s *waaaaay* simpler. To the point of ridiculousness. So, yeah, I was actually asking a legitimate question originally: Why does anybody have problems with it? There’s like only four commands you need to know, and unlike git, those commands are sensible ones. They just sorta work.

            Don’t get me wrong, “git” is fine. I specifically dislike Github, mainly because of pull-requests. Seriously, these are the bane of my existence. Before you send me a pull-request, before you even start working on it, then maybe you should, like, I dunno, *ask* if it’s a good idea? The problem with pull-requests is simply that people submit things that they think are a good idea, without ever asking you first, and you end up rejecting them entirely, and the bottom line is they spend a bunch of time for nothing. I do not accept pull requests without reviewing them, and if it’s not worth my time to do that review, then you wasted all your time writing it in the first place. This happens *constantly* because Github is bad at communication for the new-user.

            That’s why I dislike Github and rail on it a lot. No other reason. Other than shitty UI. Which exists everywhere. ;)

            Create forum topic from comment
            Reply

          • Thanks for stopping by to share the WordPress.org perspective, Otto. You wrote:

            I specifically dislike Github, mainly because of pull-requests. Seriously, these are the bane of my existence.

            Many of us really like pull requests as it allows us to quickly make changes and propose them to the author in a simple way (or the reverse, to incorporate other people’s changes quickly).

            This is exactly what we mean when we external developers talk about the arrogance of WordPress core and WordPress.org by extension. Because you, Otto Wood, dislike Github, the rest of us have to stand on our heads to get our plugins on Github to deploy to WordPress.org.

            As Coen Jacobs mentioned, the webhooks are already there. You just refuse to tap into them.

            I do hope you will eventually listen to your contributors, Otto, the plugin developers who have made WordPress the world’s most popular CMS.

            Create forum topic from comment
            Reply

          • @Alec Kinnear You act as if I’m actively preventing it somehow.. Well, I’m not. The SVN system has simply been around for longer than git or Github. I’m not planning on adding git support to it, but others certainly can if they wish. The plugin and themes repos have undergone a number of changes over the years, and perhaps that sort of thing will be added one-day.

            As for GitHub support, I’d say that seems unlikely. More likely is simply a git mirror, like is already done for core and bbpress and such: https://make.wordpress.org/core/2014/01/15/git-mirrors-for-wordpress/

            Create forum topic from comment
            Reply

          • Thanks for taking the time to share your thoughts and plans Otto. It remains that one hour of your time could save hundreds of developers thousands of hours.

            For heaven’s sake, why not just add Github push support to WordPress’s SVN repository and be done with it? Enjoy some fellow developer gratitude for a change.

            Create forum topic from comment
            Reply

        • You and Otto are clearly hardcore power-users of SVN and shell scripts and what not.

          I know it’s a BIG ASK, but c/would you please try to look at it from a non-power-user point of view? One that doesn’t even use the command line to work with Github?

          Amazing shell-script that is, what to do with it exactly?

          Create forum topic from comment
          Reply

        • Konstantin, thanks for sharing. Unfortunately Piet is right. If some of our staff are using Github to update plugin documentation, teaching them to use (let along configure) that shell script is a fair amount of overhead. Adding a step of passing that documentation over to a programmer to add to Github and then deploy via shellscript is a lot of wasted hours over the year.

          What would really help is if Otto would just add something similar to WordPress SVN to allow plugin authors to simply hook up a Github repository (a single repository not the whole account at a time) instead of SVN. I’m sure Github would be happy to add a simple signal to WordPress.org that a plugin repository should be updated. There would be no issue of shared credentials or security.

          Some things are really done more easily at the server level, directly between services.

          Create forum topic from comment
          Reply

    • “SVN is like 10 times easier to use than Git”

      I think that is a subjective statement, and as a (power) user of both, I disagree.
      Of course new users might think that SVN is easier (due to its low complexity), and you might be right that some people don’t understand version control, but especially Github has done a fantastic job to make it easy for anyone to integrate it in their work flow.

      Create forum topic from comment
      Reply

      • I’m not a power user of either and use both. Github is a whole lot easier. WordPress SVN is one of the bugbears of my working life. It requires doing handflips on every computer one uses for development (and I use four: used to be five).

        Otto, you are quite simply wrong in this case. High time WordPress got with the program and switched to Git. WordPress Core should have integrated Github compatibility eons ago. Oh, I forgot, Github charges for its services so it’s not enough GPL enough (although open source repositories are free), just like Foliovision with 98% of all our code GPL we are still barred from Wordcamp.

        Create forum topic from comment
        Reply

        • First off, GitHub is not the only managed git repository service out there. There are many self-hosted options (even GitHub offers one), and there are many completely free ones (for example GitLab). If you think the reason WordPress doesn’t use git is because of price or somehow related to licensing concerns, neither of those have anything to do with it. As I’m sure you’re aware, pricing has nothing to do with GPL compliance when done in accordance with the license.

          Nor does WordPress core really care about git vs svn. Both are version management systems, and frankly they’re both roughly equivalent to learn. It just so happens many people in WordPress are familiar with git because of GitHub. That doesn’t make git easier to learn. Just as there are 1 button push GUIs for git, there are many of the same equivalents for SVN. You don’t even need to know how to use SVN on a terminal, the same way you don’t need to know how to use git on a terminal.

          There are many actual considerations, some of which may never be satisfied with GitHub. For all the talk there is about how WordPress should just switch, or how easy it is, it’s one thing to be a person saying it, and its quite another to be the person doing that. That being said I have no desire to start some lengthy tack on discussion to a completely unrelated article, so I won’t be monitoring this post for replies.

          Create forum topic from comment
          Reply

          • Chris, point well taken about there existing alternative Git systems as well as alternative SVN systems. We did the shopping around about four years ago when someone wanted to contribute some code to one of our plugins and was astonished when we didn’t have a Github or Bitbucket account.

            At this point, Github is the collaborative weapon of choice for almost half the active authors in WordPress.org. WordPress.org is not an island unto itself. If WordPress.org cared about making external developers lives easier, it should be a priority for them to allow us to easily (single button easy) to deploy from Github to WordPress SVN.

            Yes, I know any competent coder can code his own workaround. But why the heck should so many coding hours be burned in vain in every small code shop across the land and across the world?

            Create forum topic from comment
            Reply

      • Easier or not, it is a whole different paradigm (and I don’t use that word lightly). I’ve used distributed change control systems for nearly fifteen years, and could not even imagine working on anything collaborative without the tools that provides.

        And I think “collaboration” is the key, and Otto’s attitude towards the tools that make this possible, and the developers that want to get involved (ask permission first to propose a change? FFS – open source *does not work like that*), is both astounding, and is indicative of why WordPress is stuck so far behind in what anyone would describe as a modern approach to structuring an application.

        Create forum topic from comment
        Reply

        • I didn’t say to “ask permission first”, but in any project, you want to be on-board with the other people contributing to it, and thus working as a team. To me, pull-requests just go against that flow. I don’t write code until I know what I’m writing, before I write it. I can’t really understand the flow you use if your method is to a) write the change and then b) have it rejected because it isn’t in line with the maintainer’s goals to start out with. Yes, I reject pull-requests that are unsolicited sometimes, because they don’t fit with my long-term goals for whatever project I’m working on. Why do all that work and then not have it used? Seems to me like that would put off new contributors, rather than the reverse.

          Create forum topic from comment
          Reply

          • Personally, I do raise tickets to discuss an issue before submitted a pull request on a big project, or a relatively closed project. It makes sense if I am proposing a change of direction in any aspect of that project.

            However, there are other packages that I would consider broken, or in desperate need of a change or a fix before I can use it. So I change it. I then issue a PR, and explain the reasoning behind it. The owner of that project may accept it, may ask for further changes, or may reject it. And you know, if they reject it, I do not consider myself to have wasted my time, because I have fixed something that *I* needed fixing. It was *my* courtesy and effort to offer that fix back to the project, because open source involves some give and some take. If that project owner then proclaimed, “lol, what a wast of time *that* effort was”, I would consider that quite rude. But that is what you seem to be saying.

            But on a distributed change control, it really doesn’t matter. I have my fix. Others can use my fix if they like. I can keep up-to-date with other changes, and still keep using my fix. I do this all the time, and it is great. That’s what systems such as git give you. It takes the control of how an application develops and grows away from one central place, and gives the community and other developers the ability to collaborate and explore new directions for a product.

            But then, that’s how I like it, and I’ve grown not to be precious about any code I put out there.

            Create forum topic from comment
            Reply

          • Yeah, see that’s what I especially don’t like about it. You can fork and make your changes and if those don’t get accepted back into the mainline project, then now your fork becomes further and further from the original, unless you maintain and update it as well. It puts extra burden on the developers to continue to maintain their fork, or it discourages them from contributing in the future. Additionally, if other people use that fork, then it splinters the audience and so on.

            I like having a single official project. Other people are free to fork if they like, but when you make forking literally the main way to request changes, then you lose that centralization. This is intended, of course, but I find having a central system valuable. Too valuable to really like using git for this sort of thing. Just my 2 cents.

            Create forum topic from comment
            Reply

  15. Definitely an interesting project. I am a little concerned about granting access to my repos though, seeing that permission also covers private ones (this might be a Github issue).

    I’d also like to see more documentation, e.g. how does it work with submodules, and does it work without making use of the tags directory on the plugin SVN?

    Create forum topic from comment
    Reply

  17. WordPress plugins have been the only reason to have SVN installed on my machine for years. It will be such a pleasure to be able to remove it.

    The fact that wordpress.org credentials need to be passed over to a third part to store, is a very, very poor reflection on just how much WordPress.org is dragging its feet kicking and screaming into the 21st century.

    Create forum topic from comment
    Reply

    • > The fact that wordpress.org credentials need to be passed over to a third part to store

      They don’t have to do it that way. Plugin authors can grant and revoke other users commit access to their plugins if they like. They likely just implemented it in this way because easiest, is all.

      Create forum topic from comment
      Reply

  18. A company where I used to work was using Subversion and I always hated it. Heard they switched to Git after I left. I have to use it for my plugins and am using Cornerstone (premium) to ease the pain.

    First need to hear more about Ship before forking (pun intended) over my WP.org details…

    Create forum topic from comment
    Reply

  19. Asks read and write permission on all public and private repository data, including Code, Issues, Pull requests, Wikis, Settings, Webhooks and services, Deploy keys. I would never grant so much – why are you asking so much permissions? Please only ask to be granted for only what you need!

    Create forum topic from comment
    Reply

      • Actually on second glance they ask for “repo” which is basically “public_repo” + the ability to do “public_repo” on private repositories ( so you can push from a private repository). Either way, they are asking for the smallest amount they can given the permission structure Github uses

        Create forum topic from comment
        Reply

        • That is a horrible workaround. While Big Bite Creative should be applauded for releasing this patch, it’s more than overtime for WordPress.org to introduce native support for Github. Come on Otto, why not show us how WordPress.org still cares about your third party developers.

          Create forum topic from comment
          Reply

          • You do realize that in order prevent against accidental pushes, if WordPress.org were to support GitHub, you would almost certainty have to push a button on the .org page for the plugin to deploy the update, which would mean requiring the same permissions.

            Create forum topic from comment
            Reply

          • I’m not sure that’s true Chris. When the two are tied together directly, it sounds like permissions are less of an issue. Coen Jacobs suggests:

            That ‘signal’ you talk about is already there. It’s called webhooks and the entire internet uses it to interact with things happening on GitHub (and plenty other services as well). It’s all there, WordPress.org just doesn’t integrate with them.

            Giving permissions to Github itself would be less of an issue. Your code is already there. To some extent with WordPress.org, although based on Automattic’s recent lust for data mining, there is a slight question mark in my mind.

            Create forum topic from comment
            Reply

          • Webhooks would mean automatically deploying the release. To allow for a manual, click to confirm push, you would need to use the API not the webhooks, which would mean granting WordPress.org the same “repo” permissions as listed above.

            Create forum topic from comment
            Reply

  20. I am using that but have some bugs and they don’t reply to me on twitter and by email.

    My email:
    Your service is very useful for me to upload plugins on wordpress plugin repo but have a problem.
    I’ve today updated my plugin https://github.com/Mte90/DaTask – https://wordpress.org/plugins/datask/ but I can see that not upload new files or renamed files.
    As you can see here https://plugins.trac.wordpress.org/log/datask/ I’ve uploaded manually the new files (languages file as examples) but they are ignored by Ship.
    Also not remove the files that not exists anymore.

    Also I upload the assets folder on github that contain the screenshots and the plugin icon and this is uploaded also on the trunk and tags branch, that is not required.

    Thank you for the help

    Create forum topic from comment
    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading