#### build_dir

Everything in this directory will be committed to the WordPress.org subversion repository, i.e. will be included in the downloadable zip file.

We set this to build because we have copied plugin files into build during before_deploy.

## Tagging

Assume that we have fixed some bugs and are ready to publish a new version to WordPress.org.

These commands commit the changes to the master branch but do not trigger a deployment:

Only tagged commits trigger deployment:

## Results

Head back to TravisCI and open the PHP 7.1 build log. You should see a deployment is logged.

And on the WordPress.org trac (https://plugins.trac.wordpress.org/browser/<your-plugin-slug>):

## Caveats

### svn commit Twice

Since TravisCI ships with an old version of subversion which doesn't play well with subdirectories, I do svn commit twice.

The first svn commit removes everything inside trunk. The second svn commit copies everything from build_dir to trunk.

### Experimental

This provider is still experimental and is not merged to TravisCI's official repo yet. You can keep track of TravisCI's feedback on its pull request.

Using edge doesn't merge my branch into the upstream master. There is a chance that my branch is behind the official repo. When it happens, you can fork my branch and rebase it, and then change source in .travis.yml to your GitHub repository.

## Wrapping Up

To use this deployment provider:

1. Host the plugin repository on GitHub.
2. Connect GitHub and TravisCI.
3. Add the configuration to .travis.yml.
4. Push a tag.

I hope all the above helps you deploy plugins to WordPress.org faster.

WordPress has an incredibly active economy. There are themes, plugins, libraries, and many other products that help you build out your site and project. The open-source nature of the platform also makes it a great option for you to improve your programming skills. Whatever the case, you can see everything we have available in the Envato Marketplace.