| || || || |
The pipeline requirements for our application consist of a need to compile it, package it up and then store it in a centralised location we can fetch it from at a later date. Once this pipeline has completed we'll have a package of our application ready for the Ansible pipeline to pull and pass to Ansible.
We're going to go a bit faster and into less detail than we did for the Terraform pipeline. That's because thrr
These are our stages:
1 2 3
1 2 3 4 5 6 7 8 9 10 11 12 13
After we've built the application we need to produce an artefact for the next stage.
We're using something we haven't seen before:
expire_in: inside of the
artefacts:. This means the artefact will be deleted from the pipeline's cache after the stated time and will no longer be available for download. This is a good idea if you're managing your own CI Runners and disk space is limited.
We're stating that we only want the pipeline to begin in the event there were changes to
.go files. This makes sense, because I don't want to trigger a deployment if there is nothing new to deploy.
This is the core functionality of this job: compiling and packaging the application binary and static files.
We install ZIP inside the Docker container that's running the job. It's not present by default. We build our application using the
go binary. And then we create the
.zip file we need to deploy everything to our servers and serve content.
Publishing the Application¶
1 2 3 4 5 6 7 8 9
We require the ZIP file from the build job within the same pipeline, otherwise we'll have nothing to deploy. That's what we're doing here: pulling that ZIP file (the dependency) in from the other job.
As above, we only add this stage into the pipeline if a
.go file has been manipulated and pushed into the commit.
We're using a simple
curl command to push our ZIP file to the built in GitLab Package Repository. We're using the "Generic" repository as we're not pushing a language or platform specific package.
We're not using a version for our deployment at this point in time as we're keeping things simple, but in short: when we pull this file from the Package Repository we get the last version that was pushed (based on the date/time it was pushed I believe), so we always get the latest.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Committing the Code¶
- Set your working directory to the
- Save the file as
git add .gitlab-ci.ymlto add it to the Git staging area
git commit -am 'providing a CI pipeline for our application'to commit the file to our repository
- Push the code to GitLab.com: