Continuous Integration with .NET Core and Gitlab
Starting off with CI/CD seems complicated, at least it did for me.
Turns out it’s really not that hard once you get the hang of it so let’s get right into it.
Basically, what our CI Pipeline will be doing is:
- Restore our packages
- Try to build the project
- Run our unit tests
The project structure looks like this:
.
├── .gitignore
└── src
├── Example.Test
└── Example.Web
├── Controllers
├── Properties
└── wwwrootSetting up the Gitlab CI
To configure our Gitlab CI, we’ll need a .gitlab-ci.yml file. This file describes everything our CI Pipeline will be doing for every commit.
Let’s add this file to our project root (same directory as our .gitignore ) and build it together.
When a push to our repository is done, the Gitlab CI runner will start a docker container, meaning we’ll need to include what image to use.
For .NET Core, this is microsoft/dotnet:latest . This image has the .NET Core SDK installed meaning we can access all dotnet commands.
Let’s add this to our .gitlab-ci.yml file:
This simply tells the pipeline to use this image from Docker Hub
Now let’s include the stages, these will group jobs together and each stage will be run one-by-one, in the specified order.
We’ll have a build and test stage.
This will run in the given order so first Build, then Test
Let’s set a variable for the path to our Test project:
Variables can be declared globally or per job and are called by prefixing it with a $.
The before_script section will run before every script is run. Here we’re moving to the src directory and running dotnet restore.
Keep in mind that after this script, we’ll still be located in the src directory.
Now let’s set up our first stage.
The first line is simply giving the job a name, it doesn’t have to be the same as our stage’s name but I’m not the most creative dev around so ..
On the 2nd line we’re setting our stage to build , this ensures that the job will be run before the test stage.
The script section declares all the commands which need to be executed during this stage. If any of these fail, for whatever reason, the pipeline will mark the stage as failed .
We’re already in the src directory thanks to our before_script job so we can just run dotnet build which has been declared inside a job variable, these are used the same way as global variables (by prefixing it with a $ ).
The test stage is quite straightforward, this time we’re using the global $test variable.
The final version should look like this:
That’s it! This is all the .gitlab-ci.yml needs to contain for our CI pipeline to work!
Now, when you add the CI file to git ( git add .gitlab-ci.yml ), commit and push to gitlab, you can view the commit on Gitlab and you should be able to see something similar to this:
In this picture, the pipeline is busy executing the build stage. After a minute or 2 you should be able to see that all stages have passed and our commit has been accepted.
I hope this gave you some insight on how to get started with the Gitlab CI Pipeline and gave you a jumpstart!
You can find the git repository here, the starter branch contains everything except the .gitlab-ci.yml in case you want to make one yourself :)
Clone: git clone https://gitlab.com/jelleverheyen/dotnet-ci-example.git
If you’d like to see how to build a docker image from the gitlab ci pipeline, feel free to check out my other story!
Join our community Slack and read our weekly Faun topics ⬇
