Deploying WordCamp.org

WordCamp.org has its own deployDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors. path, separate from Deploying WordPress.org. It is a GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/ repository synced into SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/., with a front-end build step in the middle.

The canonical reference is GROUPS.md in the WordCamp.org repository, which also documents the groups and GatherPress code layout. This page covers what a first-time deployer needs around it.

Everything below runs on your sandbox.

One-time setup

Add an SSHSSH Secure SHell – a protocol for securely connecting to a remote system in addition to or in place of a password. key to your GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ account if you have not already — generate it with ssh-keygen and add the public half at github.com/settings/ssh/new. Remember that you connect to the sandbox with agent forwarding, so the key can live on your own machine.

Then set up the working copy:

cd /home/wordcamp
git init .
git remote add origin git@github.com:WordPress/wordcamp.org.git
git fetch
git checkout production -f

Deploying

cd /home/wordcamp
git pull origin production

cd public_html
svn up

cd /home/wordcamp/public_html/wp-content/mu-plugins/wporg-groups-frontend
npm install --loglevel=warn 2>&1 | tee /tmp/npm-install.log
npm run build

# if you made changes to the blocks
cd /home/wordcamp/public_html/wp-content/mu-plugins/blocks
npm install --loglevel=warn 2>&1 | tee /tmp/npm-install.log
npm run build

cd /home/wordcamp/public_html
php bin/php/multiple-use/miscellaneous/sync-svn-with-git.php

The sync script waits for you. After it reports the commit, press Return — it will otherwise sit there indefinitely.

Then deploy:

deploy-wordcamp.sh

The build/ directory is generated by npm run build and is not in version control, so the build step is not optional — skipping it deploys stale front-end assets.

After deploying

Smoketest, every time. At minimum:

an individual WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They’re one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. site, e.g. https://<somecamp>.wordcamp.org
https://wordcamp.org
https://events.wordpress.org
a group page, e.g. https://events.wordpress.org/group/internal-testing-group/

Then verify that the change you shipped actually does what you expected in production.

Troubleshooting

Tree conflicts after git pull

If svn diff --summarize shows D entries for files you didn’t touch, don’t commit yet: committing would delete those files from production. Run svn status and look for tree conflicts:

D     C wp-content/mu-plugins/groups/network-export.php
      >   local file unversioned, incoming file add upon update

This happens when someone else deployedDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors. newly added files from their own sandbox. On your sandbox, git pull writes the new file to disk before svn knows about it, then svnup-all.sh brings the same file in as an incoming add and flags a conflict. It mostly hits areas where many new files land..

First check the copies match (no output means they do):

svn cat <file> | diff - <file>

Then clear the conflict:

svn resolve --accept working <file>
svn revert <file>

After that, svn diff --summarize should only list the changes you’re deployingDeploy Launching code from a local development environment to the production web server, so that it’s available to visitors..

Shared code

Some code is loaded by both WordCamp.org and WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ — see Working on a sandbox. If your change touches it, a WordCamp deploy alone is not enough: run svnup-all.sh and deploy all for WordPress.org as well, then deploy-wordcamp.sh.

WordCamp.org project page
#meta-wordcamp on Make WordPress Slack