This article describes the basic steps I followed to set up automated builds and deployments for my project with Travis CI and S3.
Create a GitHub account
Travis CI links to GitHub, so if you do not already have a GitHub account, you will need to create one.
Sign in to Travis CI with GitHub
Go to travis-ci.org and click the “Sign in with GitHub” button. GitHub should prompt you for your credentials. The first time you do this, you will need to grant Travis CI certain permissions, such as accessing your repositories, commits, etc.
Once authorized, Travis CI will display a list of your repositories.
Public repositories are immediately visible on travis-ci.org, whereas private repositories can be found on travis-ci.com. Click the slider next to the desired repository to enable builds for this repo.
Create an AWS account
If you’re going to deploy to AWS, you will need an AWS account. If you do not already have one, you can create one for free.
Create an IAM user
Once you’ve signed in to the AWS management console, navigate to the IAM service. Create a new user. Take note of the access key ID and secret access key (especially the latter, since you won’t be able to view it again). You will need these to set up the deployment. The secret key needs to remain secret, which is why you will encrypt it in a later step.
This user must have permission to write files to the S3 bucket. This can be achieved by adding them to a group that has the
AmazonS3FullAccess policy attached. You can read more about access policies here.
Create an S3 bucket
Now, navigate to the S3 service. Create a new bucket, and take note of the name you give it. You don’t need versioning or any of the other fancy features.
If you want your bucket to be accessible to the public, you might find that this is not a trivial thing. As much as it’s possible to edit the bucket’s public access settings and unblock things, I found that as soon as new files are deployed to the bucket, Amazon automatically restricts them.
One way I could ensure public access to the bucket was by creating a policy for the bucket itself. Unfortunately, S3 choked on the output generated by the AWS policy generator, so I had to do some manual tweaking.
Essentially, you want a policy that allows the principal
* (everyone) access to the action
s3:GetObject (reading a file) for any resource prefixed with the bucket’s ARN, i.e.
arn:aws:s3:::saratetra/*. For example:
Once you’ve made the necessary changes by hand, you can confirm that you’ve successfully granted public access to your bucket by looking for the orange “public” notice in S3:
Configure your Travis CI build
Builds and deployments on Travis CI are configured by including a special YAML file named
.travis.yml in the root of your repository on GitHub. Whenever you push your code, Travis CI looks for this file and kicks off a build based on its contents.
npm run build, and added a pre-build step to install Browserify:
before_script: npm install browserify -g
script: npm run build
Of course, you could do any number of things in this phase. The actual deployment steps are included in a deploy block, e.g.
- provider: s3
The example above uses AWS S3 to deploy to the “saratetra” bucket in the region “us-west-2”. For the
access_key_id property, use your IAM user’s access key ID. The optional
local_dir setting can be used to specify a particular directory that contains the specific files you wish to deploy.
You don’t want to commit the secret access key to source control without encrypting it first (this is why I left this value empty above). In the next section, I explain how to encrypt settings in Travis CI.
Note: Depending on your project, the
skip_cleanup flag above could be very important. Without it, the repository is scrubbed before deployment, which could eliminate some generated files you were hoping to deploy. 😒
Encrypt secure settings
Settings are encrypted using the Travis CLI, which is written in Ruby. You need to install Ruby before you can install the Travis CLI gem. If you’re on a Windows machine, you can do this using the Windows Subsystem for Linux (WLS).
Should you choose to go down this road, you can install Ruby using the following command:
sudo apt-get install ruby ruby-dev
My installation didn’t work out-of-the-box, so I also tried installing the following dependencies:
sudo apt-get install gcc
sudo apt-get install make
In the end, I think it was
make that did the trick.
To install the Travis CLI gem, use this command:
sudo gem install travis
Because the encryption is repository-dependent, your current working directory should be the one where your repository is located. That way, the tool can pick it up automatically. (Alternatively, you can use the
-r switch to specify the repository as a command-line parameter). Remember that on WLS you can access your Windows file system under the
sudo travis encrypt "abcd1234"
The command above encrypts the secret access key “abcd1234”. Note that I am passing only the value in the parameter to
encrypt, not the name (as I have seen some sources mention). The result is a string like the following:
Copy and paste this entire string in your
.travis.yml file, for the
secret_access_key under the
deploy block. This is where I had
"" in my earlier example. For example:
- provider: s3
To save you a couple of trial-and-error commits, note that you can use the following command to have the Travis CLI validate your
.travis.yml file offline:
travis lint .travis.yml
If you got all the steps right, the next time you push a change to your repo in GitHub, Travis CI will automatically start a new build, and finally deploy your artefacts to your S3 bucket in AWS.
Used for this article:
- Ubuntu 18.04.3 LTS
- Ruby 2.5.1p57
- Travis CLI 1.8.10
- Visual Studio Code 1.38.1