How we deploy every pull request to a seperate domain.
This article will cover, how we deploy every pull request to a seperate domain using surge.sh.
But why?
On every pull request, we do the same thing during the review process.
- We checkout the branch on our local development machines
- We build the project
- We test the build for errors
- Finally we review the code itself
This seems to be a pretty simple workflow. But for project managers and designers, it is actually really hard. And to be honest, most of us deveopers are lazy. The first two steps are just overhead we need to do to be able to properly review a pull request.
What if there could be a comment with testing urls on every pull request? We could save an enourmous amount of time by automating the first two steps. This could also be a possibility to finally integrate your designers into the review process who are unable to setup the project localy.
What do you need?
If you wan’t to adopt the described workflow, your project must compile to static (HTML, JS and CSS) files. If it doesn’t, and you need a real server running, there are other, more advanced, options out there. Check out this great article by Carlos Ribeiro.
I also assume that you already have adopted a CI process. This CI-Server must be able to execute some basic shell scripts.
Now there is only one thing missing: You need a free surge.sh account. To get one, run the following command and follow the process.
npx surge login
That’s all you need…
Let’s set it up!
Tokens
At first, we need to get all the required auth tokens. One for surge.sh to actually deploy the pull request. And another one for github, to comment back the deployed url.
To get the surge.sh token, simply run npx surge token in your command line.
To get the Github token, head over to your github account settings ( https://github.com/settings/tokens). Then generate a new token with the scope “public_repo” enabled and save it. If your repository is private, also check the top most “repo” option.
CI Server
For this tutorial, I will be using Travis CI, but you can use whatever CI-Server you prefer. The only requirement is, that you can run shell scripts on it. You also may need to adjust some variable names in the shell script, because I am using some Travis CI specific ones.
The Script
The actual script is pretty straight forward. We simply run npx surge to deploy the project and do a curl command to comment back the url.
#!/bin/bash# deploy to surge.sh
npx surge --project ${BUILD_DIR} --domain ${TRAVIS_PULL_REQUEST}.${SURGE_SUBDOMAIN}.surge.sh# comment url to pull request
curl -H "Authorization: token ${GITHUB_TOKEN}" -X POST -d "{\"body\": \"❤️ I have deployed this pull-request for you: \nhttp://${TRAVIS_PULL_REQUEST}.${SURGE_SUBDOMAIN}.surge.sh\"}" "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"
That’s it.
But first you need to define the environment variables:
SURGE_LOGIN = your surge account email
SURGE_TOKEN = result of npx surge token
GITHUB_TOKEN = your github access token with the `repo` scope
BUILD_DIR = the directory where the build output can be found
SURGE_SUBDOMAIN = the surge.sh subdomain where you would like your pull requests to be located.
Okay, to make this thing shippable we should add some error handling. But I will skip this here. The full script can be found in my demo repository: https://github.com/adrianjost/DEMO-Surge.sh-Pull-Deploy/
A more advanced example with multiple subprojects can be found here.
I hope you liked my very first article on medium, if so please let me know. 🤗
And if you have any questions, just drop a comment.
