Deployer App Pushes Plugins from GitHub to WordPress.org

deployer

Arūnas Liuiza, like many other WordPress developers, prefers to develop his plugins on GitHub, thanks to the collaborative tools for issue tracking, merging, and pull requests. Hosting and developing open source projects on GitHub is much easier than trying to get any participation from the community via a plugin’s Subversion repo on WordPress.org.

For these reasons Liuiza decided to create Deployer, a service that allows plugin developers to publish plugins to the WordPress.org Plugin Directory directly from GitHub, without using Subversion at all. He first presented the app at WordCamp Lithuania in September 2015, but hasn’t yet given it much promotion.

“I wanted to streamline the process of publishing plugins from GitHub to WordPress.org,” Liuiza said. “I have more than 10 plugins in the repository, so I want to do things fast and easily.”

Last July we covered a similar service called Ship, which offered a hassle free approach to shipping plugins directly from GitHub to WordPress.org. Liuiza, with 10 plugins to maintain, was initially excited about Ship but found there were several drawbacks.

“First, Ship required pretty wide access to my GitHub account,” he said. “GitHub does not provide granular API access, so I’d have to grant Ship access to all my GitHub repos, not only the one I wanted to publish from. That includes my private repos.

“Second, Ship needed my WordPress.org credentials. And because it will need to use them regularly, they could not really hash them and had to store them in plaintext. Again, that would give Ship access to everything in my WordPress.org account. All plugins, all themes, all comments, all translations, etc. Everything.”

This inspired Liuiza to create Deployer with a new approach that doesn’t require giving away access and credentials.

“In comparison to Ship, Deployer takes a quite opposite stance when it comes to requiring access,” he said. “Where Ship requests a lot of privileges, Deployer asks for almost none.

“Deployer asks no privileges on GitHub. Public GitHub repositories can be cloned without any limitations by anyone, so Deployer does that. Deployer would need access to set up a WebHook for itself, but instead of requesting access Deployer provides step by step instructions for user how to set up the Webhook manually,” Liuiza said.

The Deployer service doesn’t handle any sensitive authentication data for GitHub or WordPress.org. Instead, it requires a more manual setup.

“Instead of requiring user’s WordPress.org credentials, Deployer has a dedicated WordPress.org user, deployer,” Liuiza said. “The plugin author has to manually add the deployer user to his plugin’s committer list, thus allowing that user to commit code to plugin’s SVN repository. This also enhances security, because WordPress.org can identify all the commits, made by the deployer user and roll them back in case there is a breach from Deployer’s side.”

Pushing a new version of a plugin from GitHub to WordPress.org is as easy as tagging the new version on GitHub. Deployer even handles updates to the readme.txt file and the assets directory.

“In terms of technology, Deployer is basically a single PHP file, that parses calls from GitHub Webhooks and then executes a bunch of shell commands (mostly git and svn) on a small Linux VPS box,” Liuiza said.

Since launching last year, 34 plugins have been registered with Deployer, although Liuiza said he doesn’t keep logs on how many developers are using it regularly. He doesn’t currently have plans to monetize it but is happy to accept donations.

“Unless it becomes a drain on my resources (and it does not seem likely at this point) it will always be a free tool,” Liuiza said.

18 Comments


  1. Very nice, I wouldn’t use Ship for reasons stated. This sounds just about perfect.

    Report


    1. The short answer is because WordPress predates Git by about a year. We’ve been using SVN for longer than Git has actually existed. Switching to git would take a fair amount of work, for not a whole lot gain.

      That said, work is being done on things like git syncing and other means of making WordPress and associated bits available for those who prefer to use Git or SVN. That work continues.

      Report


  2. Deployer has a dedicated WordPress.org user, deployer

    Does this mean that if someone malicious obtains the password for that user (it’s still, unfortunately, the case that wordpress.org has no two-factor authentication system), then they could push their own updates to every plugin from any author that’s in the Deployer system?

    Report


    1. Unfortunately, that is true. But with a single compromised user, WordPress.org maintainers could very easily revert those bad commits. I am following the proposal of Otto here, that he expressed when critiquing Ship. It is not a perfect solution, but in my opinion – a much better than storing a lot of plain text passwords for all the user’s.
      I wish WordPress.org had a better (or any, for that matter) API to handle those things, but I have no better solution for now. And I am open to suggestions :-)

      Report


      1. I wish WordPress.org had a better (or any, for that matter) API to handle those things

        I have no argument with that!

        It’s very concerning to know that, for every plugin on your site, only a single password needs to be cracked in order for someone malicious to slip an evil new version onto wordpress.org, which people would start updating to instantly.

        Sure, it would hopefully get caught, within a few hours probably (a clever attacker would time his release for the sleeping hours of the plugin developer) – but with big plugins, that’s long enough for the malicious actor to slip his evil code onto thousands of sites. So, there’s a big prize, and a low barrier…

        Report


      2. Just to be clear – my comment above is a general one about wordpress.org plugins, not about Deployer. i.e. by “every plugin on your site”, I mean our WordPress websites.

        Report


  3. I use Ship to deploy some of my plugins from GitHub to WordPress.org, but after reading this, I’ve decided to give Deployer a shot!

    Sarah, thanks for sharing this.

    Liuiza, thanks for building such a wonderful service like Deployer.

    Report


  4. Sounds neat! One question…

    You say it’s a single php file… How tough would it be for me to use that php file and configure things on my end rather than use the Deployer service?

    Thanks!
    Toby

    Report


    1. Hi Toby. I haven’t released the code yet, but once I do, then you could run your own instance. Assuming your environment allows you to run git/svn shell commands, of course.

      Report


  5. I actually signed up a while ago then never actually tried it and deciding to remove the ‘deployer’ god from my plugin. I really not feel comportable with this. I wish something like this would be open source. I wound understand it if people build a payed service but what the point of Ship and Deployer of they are gratis and not doing any data grabbing? Or do they?

    I want a think I can install on ‘my’ VPS I control and at least somehow trust and then put some Webhook key, my wp.org user and pass and a config file, fire that thing up and forget about it. I do not want to sign my valuable data to some other person/service I do not know. I saw this thing that may be what I am looking for but it seems based on something that sits in some Automattic repo that may be better maintained. I not quote got the difference, the documentation is not really there and nobody seems to use it … thats why I never got to try it.

    Report


    1. Hi Nico! I appreciate the feeling. That is how Deployer came about in the first place – I wanted a tool for my own workflow. Then I helped a client who did not want to tackle SVN. And then I thought it might be useful to others out there, so I added a public registration form and talked about it a bit.

      As for providing the service for free – I see it as part of me giving back to the WordPress community. I might not be a big-shot name in WordPress circles, but I still believe the things I have released (Gust, Content Cards, etc.) give me a bit of trust capital within the community. And they have donated more than 100 cups of coffee to support various of my WordPress related projects to date.

      As for your “valuable data” – if you are using Deployer, your project is open source and I do not believe I have access to any data you are not giving away anyway. Deployer only works with public GitHub repositories, and WordPress.org repository is also public. I do not believe I could have made this service in a way that requires less access and still works.

      As for making it open source, I only try to release stuff that I am prepared to support and document. Deployer is not something you can run on any shared hosting nor do I intend to make it such. It will require some technical knowledge to set up and run. I believe people who have that level of knowledge already have their own scripts in place, or can find better solutions for this – bash scripts, grunt tasks, etc. But hey, if you really need it – here is the class that does the actual work: https://gist.github.com/ideag/fceb74ea31b5ee565b33

      Report


  6. Not really feeling the concept of open source runs deep in the WP community any more…like everyone’s following the services model of Automattic who realised that knowledge differentials are actually important to making money.

    This is exactly what needs to be released as open source so people can securely run their own services as well as review the security of the code. Otherwise there’s still a massive security target here.

    The problem, of course, is that the chance to ever make money from his work will then disappear for Liuiza…unless he can turn it into some sort of multi-tier service *and* get lucky…

    Report


  7. This looks really cool. I tried setting it up on one of my plugins last night and while everything seemed to be configured correctly and the webhook is firing, the plugin isn’t getting deployed to .org. Any ideas Arūnas?

    Report


  8. Sound interesting. The repeated process of export files from git to svn takes me sometimes and it doens’t work well when I switch to another computer. It’s definitely worth a try.

    Report

Comments are closed.