I have a solution with several .NET projects in it. I use GitLab, not self-hosted, for version control and would like to start using their CI tools as well. I have added the following .gitlab-ci.yml
file to my root:
stages: - build - test build_job: stage: build script: - 'echo building...' - 'msbuild.exe Bizio.sln' except: - tags test_job: stage: test script: - 'echo: testing...' - 'msbuild.exe Bizio.sln' - 'dir /s /b *.Tests.dll | findstr /r Tests\\bin\\ > tests_list.txt' - 'for /f %%f in (tests_list.txt) do mstest.exe /testcontainer: "%%f"' except: - tags
The build
stage always fails because it doesn't know what msbuild
is. The exact error is:
/bin/bash: line 61: msbuild.exe: command not found
After some investigating, I've figured out that I'm using a shared runner. Here is the entire output from the job run:
Running with gitlab-runner 10.6.0-rc1 (0a9d5de9) on docker-auto-scale 72989761 Using Docker executor with image ruby:2.5 ... Pulling docker image ruby:2.5 ... Using docker image sha256:bae0455cb2b9010f134a2da3a1fba9d217506beec2d41950d151e12a3112c418 for ruby:2.5 ... Running on runner-72989761-project-1239128-concurrent-0 via runner-72989761-srm-1520985217-1a689f37... Cloning repository... Cloning into '/builds/hyjynx-studios/bizio'... Checking out bc8085a4 as master... Skipping Git submodules setup $ echo building... building... $ C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Bizio.sln /bin/bash: line 61: msbuild.exe: command not found ERROR: Job failed: exit code 1
It looks like the shared runner I have is using a Docker image for Ruby, which seems wrong. I don't know how I can change that or select a different one that can be used for .NET. After some further investigating I'm getting worried that I'll have to jump through a lot of hoops to get what I want, like using an Azure VM to host a GitLab Runner that can build .NET apps.
What do I need to do to use GitLab's CI pipelines to build my .NET solution using a non-self-hosted GitLab instance?
As you can see above, to configure a runner and also pipelines for GitLab is not a big deal. . NET Framework brings a bit more of complexity because of several tools you need to have configured as well, but once you did it, it's done for that runner and project.
Both tools come with their pros and cons. While Gitlab gets an edge in code collaboration and version control, Jenkins fares well in continuous integration. As such, you cannot rate one tool over the other in the Gitlab vs Jenkins CI/CD battle.
GitLab Continuous Integration and Delivery automates all the steps required to build, test and deploy your code to your production environment. Continuous integration automates the builds, provides feedback via code review, and automates code quality and security tests.
You should be able to setup your own shared runner on a machine with the Framework 4 build tools on it (either using a Docker image, like microsoft/dotnet-framework-build, or just your native machine).
The simplest case to get going is using your own desktop, where you know your solution already builds. (Since using Docker images for the build is absolutely possible, but involves all of the extra steps of making sure you have docker working on your machine).
Download gitlab-runner on your computer from https://docs.gitlab.com/runner/install/windows.html
gitlab-runner register
gitlab-runner install
gitlab-runner start
Whew. Now that runner is setup, it should be activated when you push a commit or a merge is requested.
If you are having issues still with the .gitlab-ci.yml file building properly, you can debug it locally (without having to keep triggering it through gitlab.com) by going to your solution folder in the command line and then executing c:\gitlab-runner\gitlab-runner build
(To test the build step, for example).
If the build step has problem finding your solution file, you might want to try changing it from 'msbuild.exe Bizio.sln' to 'msbuild.exe .\Bizio.sln'
To complement the answer by reallyrae, the other option for .Net Core apps is to include a call to the container as the first line in your .gitlab-ci.yml file. This will allow the build to happen on a shared GitLab.com runner.
image: microsoft/dotnet
If you are building a traditional .Net application, you can try the mono docker image. If that doesn't work for you, the local runner is, as far as I know, your only option.
image: mono:latest
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With