使用GitLab CI Pipeline构建.NET解决方案

Question

我有一个包含几个.NET项目的解决方案。我使用GitLab而不是自托管来进行版本控制，并且也想开始使用他们的CI工具。我已将以下.gitlab-ci.yml文件添加到我的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

build阶段总是失败，因为它不知道msbuild是什么。确切的错误是：

/ bin / bash：第61行：msbuild.exe：找不到命令

经过一番调查，我发现我正在使用共享的跑步者。以下是作业运行的整个输出：

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

看起来我的共享运行器正在使用Ruby的Docker镜像，这似乎是错误的。我不知道如何更改它或选择可用于.NET的另一个。在进行了一些进一步的调查之后，我开始担心我将不得不通过大量的工作来获得我想要的东西，例如使用Azure VM来托管可以构建.NET应用程序的GitLab Runner。

使用GitLab的CI管道使用非自托管GitLab实例构建我的.NET解决方案需要做什么？

Answer 1

您应该能够在具有Framework 4构建工具的计算机上设置您自己的共享运行器（使用Docker映像，如microsoft / dotnet-framework-build，或者仅使用本机）。

最简单的情况是使用您自己的桌面，您知道您的解决方案已经构建。 （因为使用Docker镜像进行构建是绝对可行的，但需要确保让Docker在您的机器上工作的所有额外步骤）。

• 从https://docs.gitlab.com/runner/install/windows.html下载计算机上的gitlab-runner 在计算机上创建一个目录（C：\ gitlab-runner） 将最新的二进制x86或x64下载到该文件夹 将二进制文件重命名为“gitlab-runner.exe”
• 为你的跑步者获取一个gitlab-ci标记 可能最简单的方法是在gitlab.com上转到您的项目，然后转到设置 - > CI / CD并展开常规管道设置。 在Runner Token部分中，单击Reveal Value按钮以显示标记值。在跑步者注册步骤中您将需要这个。
• 根据Registering Runners - Windows注册gitlab runner 打开提升的命令提示符（以管理员身份运行） cd到c：\ gitlab-runner 键入gitlab-runner register 注册提示将指导您完成注册跑步者的步骤，但简而言之，您将投入使用 gitlab.com作为您的协调员URL，从您的项目中输入令牌 给你的跑步者一个名字 标记您的跑步者（以便您可以将其与能够构建，测试等的项目相关联 - 为简单起见，您现在可以跳过标记） 允许它运行无标记的工作（再次，简单，说真的） 锁定当前项目的跑步者（简单，说真） 并选择执行程序（输入shell，基本上是说使用Windows命令行）
• 安装gitlab-runner作为服务，因此它总是检查要做的工作 在命令提示符下，键入gitlab-runner install 然后输入gitlab-runner start （现在，如果你去服务，你会看到列出的gitlab-runner，它应该正在运行 - 就在何时/如果跑步者崩溃，你应该去服务重启它）

呼。现在已经设置了运行器，它应该在您提交提交或请求合并时激活。

如果您仍然在正确构建.gitlab-ci.yml文件时遇到问题，可以在本地调试它（无需通过gitlab.com继续触发），方法是在命令行中转到解决方案文件夹，然后执行c:\gitlab-runner\gitlab-runner build（例如，测试构建步骤。

如果构建步骤在查找解决方案文件时遇到问题，您可能需要尝试将其从“msbuild.exe Bizio.sln”更改为“msbuild.exe。\ Bizio.sln”

Answer 2

为了补充真实的答案，.Net Core应用程序的另一个选项是将容器调用作为.gitlab-ci.yml文件中的第一行。这将允许构建在共享的GitLab.com运行器上发生。

image: microsoft/dotnet

如果要构建传统的.Net应用程序，可以尝试单声道的docker镜像。如果这对你不起作用，据我所知，本地选手是你唯一的选择。

image: mono:latest

Answer 3

或多阶段构建：

stages:
  - build-dotnet
  - test-dotnet
  - build-mono
  - test-mono

build-dotnet:
  stage: build-dotnet
  image: microsoft/dotnet:latest
  before_script:
    - "cd source"
    - "dotnet restore"
    - "cd .."
    - "cd samples"
    - "dotnet restore"
    - "cd .."
  script:
      - "cd source"
      - "dotnet build"
      - "cd .."
      - "cd samples"
      - "dotnet build"
      - "cd .."

build-mono:
  stage: build-mono
  image: mono:latest
  before_script:
  script:
    - nuget restore ./source/Source.sln
    - msbuild 
        /p:Configuration="Release"
        /p:Platform="Any CPU" 
        "./source/Source.sln"