代码之家 › 专栏 › 技术社区 › Will Custode

建筑NET解决方案,使用GitLab CI管道

gitlab-ci-runner gitlab continuous-integration msbuild .net

Will Custode · 技术社区 · 7 年前

我有几个解决方案。NET项目。我使用GitLab(而非自托管)进行版本控制,并希望开始使用他们的CI工具。我添加了以下内容 .gitlab-ci.yml 文件到我的根目录:

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

看起来我的共享runner使用的是Ruby的Docker图像,这似乎是错误的。我不知道如何更改或选择一个可用于的其他选项。净额。经过进一步的调查,我开始担心我将不得不跳过很多障碍来获得我想要的东西,比如使用Azure VM来托管可以构建的GitLab Runner。NET应用程序。

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

3 回复 | 直到 7 年前

reallyrae 7 年前

您应该能够在带有Framework 4构建工具的计算机上安装自己的共享runner(可以使用Docker映像,如microsoft/dotnet Framework构建,也可以仅使用本机)。

最简单的情况是使用您自己的桌面,您知道您的解决方案已经在那里构建。(因为在构建中使用Docker映像是完全可能的,但需要所有额外的步骤来确保Docker在您的机器上工作)。

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

呼。现在已经设置了runner,当您推送提交或请求合并时,它应该被激活。

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

如果生成步骤在查找解决方案文件时遇到问题,您可能希望尝试将其从“msbuild”更改。exe Bizio。sln“到”msbuild。exe。\比齐奥。sln'

user7504939 6 年前

为了补充reallyrae的答案,另一个选项是。Net核心应用程序将包含对容器的调用,作为您的第一行。gitlab ci。yml文件。这将允许在共享GitLab上进行构建。com运行程序。

image: microsoft/dotnet

如果你正在建造一个传统的。Net应用程序,您可以尝试mono docker映像。如果这对你不起作用,据我所知,当地的跑步者是你唯一的选择。

image: mono:latest

moljac 5 年前

或多阶段构建:

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"