101. Triggering CD workflow


In the last video, we defined the image and first job for our CD pipeline. In this video, we'll get GitLab to actually run the pipeline.

Triggering it is as simple as committing our code and pushing it to GitLab's server. Before we do that, though, let's create a dedicated Git branch for this purpose.

First, make sure you're using a terminal from outside the Vagrant environment. You'll see in my IDE I've got two terminal instances, one named Guest, and one named Host.

From the host, make sure you have a branch checked out that has all the most up-to-code from your project. I recommend you check out the main branch for this module which you can do by typing:

$ git checkout module10/115

This ensures that you have the completed code from the PrintBay project including all the tests.

From this branch, let's create a new branch that will be used for deploying the app. So type:

$ git checkout -b deploy

That will create and checkout a new branch called deploy. This branch should be used anytime you're ready to deploy new features to the live app, which you'll do by merging the code into this branch.

Let's now do a Git commit to commit the GitLab YAML file to the branch.

$ git add --all
$ git commit -m "Adding CD config file"


Now that we have a branch with the CD config committed to it, we need to push the branch to the GitLab server to trigger the CD workflow.

I'm presuming that you have your own repository for PrintBay on GitLab, which you should do if you've followed the instructions from the beginning of the course.

In the terminal, type git remote -v and you'll get a list of the remote servers linked to this repository.

Hopefully you'll have GitLab as your origin remote. If you don't, the following steps won't work, so be sure to get that set correctly first.


In order to push the deploy branch to GitLab go ahead and type

$ git push origin deploy

GitLab CI UI

Go ahead and login to the Vue.js Developers Git server now via the user interface. Go to the PrintBay code repo and come down to CI/CD section which you can see on the left menu here, and click on "pipelines".

You'll see that there is a pipeline that has just run and the status is "passed". Note that this is on the deploy branch, and if you check the commit message, it corrosponds to the one we just created.

You can see over here on the right how long it took, which was 18 seconds. That is relatively quick because there's only one simple job in the pipeline.

Let's now click on this pipeline to see further details about it.

Build job

Within our pipeline we have a visualisation of the different jobs. Currently, we just have this one job, called build.

We're eventually going to end up with multiple jobs in our pipeline as we progress, including tests and deploy job, but we'll get to those later.

Now, if we click on the build job in the pipeline, we see a snapshot of the terminal output that was captured as the job ran. Let's quickly go through it so we can see what happened.

GitLab runner

At the very top, you'll see it says "running with GitLab runner". You can think of the GitLab runner as a service that receives our GitLab configuration and then triggers the build of our virtual environment where the workflow runs.

On the next line, it says "using Docker execute with node-10.15.3". This means it found the Docker image we specified and downloaded it and launched it.

Now, down here, it says "fetching changes with Git depth set to 50". This means that now the virtual machine has been set up, the runner has used Git to pull the code base into this virtual environment.

Once the code is checked out from git, you'll see down here, you'll see it says "echo Hello World" which means our build job ran with the VM.

It also says our job succeeded because the process finished without any errors.

NPM install

Now that we've got our pipeline working, let's make our build job actually do something meaningful rather than simply echoing "Hello World".

The first thing we want our deployment pipeline to do is build the app. This is the first line of defence against faulty code, and logically should come first in the pipeline, since if you can't build the app, you can't test it.

So let's change the script from echo "Hello World" to npm i or npm install if you prefer, keeping in mind that NPM is included in our node Docker image, so we shouldn't have any problems running this command.


image: node:10.15.3
  script: npm i

Let's now commit and push the new code by going to the terminal again and typing:

$ git add --all
$ git commit -m "Installing app"
$ git push origin deploy

Back in the GitLab UI, you'll see we now have a second pipeline. So let's inspect that and we see the build job has passed, meaning our app installed successfully.

Inspecting this job, we see almost identical output to before, only now we have the output of the npm install as well.