Once the CI scenario has been set up for testing the changes on the website, it’s time to configure the CD part for the QA deployment. So, what are we trying to achieve? Easily spoken, when the git commit has passed all required tests I would like to upload the generated site into my test tenant. This is a little bit tricky. I already wrote in my first post about Github Actions that my website is not hosted somewhere in the Github space, instead, it is hosted by a third-party provider in my web-space area. The third-party provider offers an SFTP option to upload the site data. This completely fine when the upload part is done manually but not that easy anymore when a CD tool should do the upload. Fortunately, Github Actions has options for this as well. But before we start with this, let’s have a look at how my development.yml looks now with the CD part included:
name: Development Workflow on: [push] jobs: test: name: CI Pipeline runs-on: ubuntu-latest steps: - name: Checkout master uses: actions/checkout@v1 - name: Set up Ruby 2.6 uses: actions/setup-ruby@v1 with: ruby-version: 2.6.x - name: Setup bundler and required gems run: | gem install bundler bundle install --jobs 4 --retry 3 - name: Build and test the website run: bundle exec rake deploy: name: CD Pipeline QA needs: test runs-on: ubuntu-latest steps: - name: webfactory/ssh-agent uses: email@example.com with: ssh-private-key: $ - name: Checkout master uses: actions/checkout@v1 - name: Set up Ruby 2.6 uses: actions/setup-ruby@v1 with: ruby-version: 2.6.x - name: Set up lftp run: sudo apt-get install lftp -y - name: Setup bundler and required gems run: | gem install bundler bundle install --jobs 4 --retry 3 - name: Build and deploy the website to QA run: bundle exec rake deploy:qa env: SSH_DEPLOY_SERVER: $ SSH_DEPLOY_USER: $
Compared to the initial YAML I’ve described in my former post, you might have noticed that I have added a second job called deploy. The actions in that job are pretty much the same as in the test job. This job should also create a new Ubuntu container, it should install Ruby and the Gems required to create my Jekyll site. Two things, however, differ from the test job, the first one is an action called “webfactory/ssh-agent”, the second one is a deploy action that uses a special environment. Let’s start with the second one, as mentioned, I use a special environment for this action. The rationale behind this is, that I need to pass the target and the credentials to deploy the generated site to this target. To achieve this I created three secrets in the Github secret area of the repository:
In the end, these secrets are “only” variables that will be made available in the container that is started with Github Actions. Nonetheless, this is the missing feature to generate deploy scripts without storing secrets in the code that is pushed to Github. Instead, the secrets are kept outside of the container in a secure area at Github ready to be used at each deploy. In detail this means, I use environment variables in my Rakefile to define the target where I would like to deploy the generated site as well as the user that should be used for the deploy. In principle, it would be possible as well to deploy a password with that way but I made the decision to use a cryptographic key instead.
To make things easier for me I used a predefined action called ssh-agent. This action reads the cryptographic key stored in SSH_PRIVATE_KEY and adds it to the ssh-agent installed in the container. With this mechanism in place, I’m able to deploy the generated site code with a passwordless login.
With the next post, I will finish this series about Github Actions by describing how to finally deploy the generated site to production.