web-dev-qa-db-ja.com

GitLab CIおよびMsBuild（テスト付き）

私はsvnのレポジトリをGitLabでgitに移行している最中です。

今、私はGitLab CIとの継続的な統合の実装があることを見てきました。それを試してみたいだけです。

Runnerをインストールして構成しましたが、.gitlab-ci.ymlファイルがないとGitlabから苦情が出ています。

私は継続的な統合にすでにTeamCityを使用しているので、ビルドスクリプトの記述にあまり力を入れたくありません。

私のソリューションを構築してすべてのテスト（MSTests）を実行するだけのgitlab-ci.ymlファイルの基本的な例がどこにあるかを誰かに教えてもらえますか？

continuous-integrationgitlabgitlab-ci
17
Jürgen Steinblock

どうやら単純な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がテストについて何も知らないことを知っています。エラーコードを返すコマンドラインがあります。

24
Jürgen Steinblock

これは私が最終的に使用したものです。すべての* Tests.Dllを1回の実行で実行します。

  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%
1
Gluip

JürgenSteinblock 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ビルドディレクトリ。これには、中間ファイルを使用しないという利点があります。

1
cid

この質問が開かれてから少し状況が変わったので（そして現在、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がある場合）。 onlyコミット時にユニットテストを自動的に実行する場合は、ビルドステージを無視します。

0
Ethan DeLong