Add the following configuration to
~/.ssh/config file. Replace the
IdentityFile setting with path to any SSH key you have registered with GitHub. This will make it easier to connect to a container quickly later.
Host manage.rets.ci.staging User rets-ci.manage.rets.ci.staging Hostname ssh.wpcloud.io IdentityFile ~/.ssh/github.pem Host manage.rets.ci.production User rets-ci.manage.rets.ci.production Hostname ssh.wpcloud.io IdentityFile ~/.ssh/github.pem
After this, you can connect to the container you need via a command like so:
If you have issues connecting, run the following command for clues:
ssh manage.rets.ci.staging -v
As demonstrated lower, you can easily move in and out of containers. Once you SSH into the container, you will have access to all the standard Node.js tools such as
Configure IDE for SFTP Upload
Configure your IDE client to automatically upload files via SFTP from your local cloned repository directory to the corresponding container. Using the automatic SFTP upload method has the following benefits:
- keeps the repository (codebase) files locally, allowing your IDE to index them and for you to easily push/pull
- uses our deployed container(s) to run the actual application in a standard pre-configured environment
- allows you, and others, to easily preview your work at the
*.c.rabbit.cidomain each container has
In other words, you do not need to run MAMP, or any other servers, locally.
A near-identical SFTP configuration is used to connect to different containers, only the
User changes. As with the SSH connection, replace SFTP Key path with any GitHub key you have.
If your IDE can not upload files over SFTP, you may also test connectivity via the terminal using the
sftp -v manage.rets.ci.staging
Below are some short screencasts demonstrating the workflow.
Configure IDE to SFTP upload
Adding SFTP upload to PHP(Web)Storm then making a change locally. The change is automatically uploaded to the
staging container and PM2 restarts the main server process.
Enable Automatic Upload and Make a Change
We verify that container and local do not have any un-staged changes, then enable Automatic upload and add a change. The change is uploaded to container automatically.
Make Changes and View in Web
We verify that PM2 restarts the service and see our change in a browser.
We commit our work and see it automatically deploy to the container.
Production branches are protected, so we can not (shout not) push directly to them. To deploy work to production, we use the GitHub Pull Request mechanism demonstrated below. Take note that files are deployed to the production container automatically.
- The Node.js service started in container should have auto-restart enabled so service is reloaded every time a file is changed after an SFTP upload.
- Remember that every time you commit our CI services "refresh" all files in the container. So if you had created any files in the container that were not committed to GitHub, they will be removed from the container.
- Commit from your local machine. Containers do have SSH access to the repository and you could commit/push/pull from the container but its best practice to do it from local machine only.
- Production deployments must be done via GitHub pull request into the
- If you add/remove an SSH key from GitHub, let us know, there is no automatic re-fetching of SSH keys.
- Reference GitHub issues in your commit messages.
- Be sure to commit at least once per day.