I am in the process of migrating my svn repsitories to git with GitLab.
Now I have seen that there is a continuous integration implementation with GitLab CI and just want to try it out.
I already installed and configured a Runner but Gitlab complains that I don't have a .gitlab-ci.yml
file.
I already use TeamCity for continuous integration so I don't want to put too much effort into writing a build script.
Can anybody tell me where I can find a basic example of a gitlab-ci.yml
file that basically just builds my Solution and runs all tests (MSTests)?
答案 0 :(得分:20)
显然没有简单的msbuild示例,但这应该让你开始:
variables:
Solution: MySolution.sln
before_script:
- "echo off"
- 'call "%VS120COMNTOOLS%\vsvars32.bat"'
# output environment variables (usefull for debugging, propably not what you want to do if your ci server is public)
- echo.
- set
- echo.
stages:
- build
- test
- deploy
build:
stage: build
script:
- echo building...
- 'msbuild.exe "%Solution%"'
except:
- tags
test:
stage: test
script:
- echo testing...
- 'msbuild.exe "%Solution%"'
- dir /s /b *.Tests.dll | findstr /r Tests\\*\\bin\\ > testcontainers.txt
- 'for /f %%f in (testcontainers.txt) do mstest.exe /testcontainer:"%%f"'
except:
- tags
deploy:
stage: deploy
script:
- echo deploying...
- 'msbuild.exe "%Solution%" /t:publish'
only:
- production
确定要运行哪些测试有点棘手。我的惯例是每个项目都有一个文件夹测试,其中测试项目以模式MyProject.Core.Tests命名(对于名为MyProject.Core的项目)
正如对gitlab-ci的第一反馈
我喜欢简单和源代码控制集成。但我希望能够在执行之前修改脚本(特别是在更改脚本时),但我可以成像重新运行特定的提交并注入变量或更改脚本(我可以使用teamcity执行此操作)。或者甚至忽略失败的测试并再次重新运行脚本(我使用teamcity做了很多)。我知道gitlab-ci对我的测试一无所知我只有一个返回错误代码的命令行。
答案 1 :(得分:1)
作为Jürgen Steinblock answer的附录,我想为测试阶段脚本建议一个更简单的替代方案:
variables:
SOLUTION_DIR: "MySolution"
BUILD_DIR: "Release"
TESTER: "vstest.console.exe" # or "mstest.exe /testcontainer:"
before_script:
- call "%VS120COMNTOOLS%\vsvars32" # import in path tools like msbuild, mstest, etc using VS script
test:
stage: test
script:
- for /f %%F in ('dir /s /b %SOLUTION_DIR%\%BUILD_DIR%\*Tests.dll') do set dllPath=%%F
- "%TESTER% %dllPath%"
这将在所有找到的测试项目二进制文件上启动测试,这些二进制文件在构建目录中以*Tests.dll
的约定结束。这样做的好处是不使用中间文件。
答案 2 :(得分:1)
这是我最终使用的。它在一次运行中运行所有* Tests.Dll。
dir /s /b *.Tests.dll | findstr /r bin\\Debug > testcontainers.txt
for /f %%x in (testcontainers.txt) do set list=!list! %%x
set list=%list:~1%
vstest.console.exe %list%
答案 3 :(得分:0)
自从这个问题被提出以来,事情发生了一些变化(现在MS在VS中支持核心/ Linux docker部署),我想我应该分享我的解决方案。
# Default image is docker:stable
image: docker:stable
# Define deployment stages
stages:
- Test
- Build
# We use docker-in-docker (dind) for building docker images (build stage)
services:
- docker:dind
# Run unit test on dotnet core sdk image
test:
stage: Test
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- dotnet restore "${CI_PROJECT_DIR}/Project.Tests/Project.Tests.csproj"
- dotnet test "${CI_PROJECT_DIR}/Project.Tests/Project.Tests.csproj"
tags:
- docker
only:
- master
# Only build when testing passes, build using Dockerfile/dind
build:
stage: Build
# Print docker instance details for logging/diagnosing
before_script:
- docker info
- docker login registry.gitlab.com -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD}
script:
- docker build -t ${CI_REGISTRY}/${CI_PROJECT_PATH}:latest .
- docker push ${CI_REGISTRY}/${CI_PROJECT_PATH}:latest
after_script:
- docker logout ${CI_REGISTRY}
tags:
- docker
only:
- master
when: on_success
这应该在您的解决方案上运行MS单元测试,并且如果测试通过,则可以从它们创建映像(前提是gitlab-ci.yml文件旁边有一个Dockerfile)。如果您只是 想要对提交自动执行单元测试,请忽略构建阶段。