À l'aide de GitLabCI avec C#

Je travaille sur une application en C#, et je voulais essayer le GitLab CI. Tout ce que je peux voir, c'est Ruby et ne pouvez pas trouver toute l'information sur la façon de construire une application en C# à l'aide.

Quand je lance les paramètres de test, je fais de la validation mais je n'ai pas mon construire.

À l'aide de GitLabCI avec C#

Comment dois-je faire un simple construire? Quelle commande dois-je utiliser? Je n'ai pas l'esprit si je reçois un échec lors de la construction (mais à construire).

Avez-vous un .gitlab-ci.fichier yml que vous pouvez partager?

OriginalL'auteur Andres Rojano Ruiz | 2015-11-04

  1. 37

    Je voulais juste partager mon .gitlab-ci.yml complet avec des tests unitaires. Vous devrez ajuster vos nuget et peut-être d'autres chemins. C'est pour un projet unique dans une solution du même nom.

    variables:
  PROJECT_NAME: "ProjectNameGoesHere"
before_script:
  - echo "starting build for %PROJECT_NAME%"
  - echo "Restoring NuGet Packages..."
  - d:\tools\nuget restore "%PROJECT_NAME%.sln"
stages:
  - build
  - test
build:
  stage: build
  script:
  - echo "Release build..."
  - '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "%PROJECT_NAME%.sln"'
  artifacts:
    untracked: true
test:
  stage: test
  script:
  - echo "starting tests"
  - cd %PROJECT_NAME%Tests/bin/Release
  - '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:%PROJECT_NAME%Tests.dll'
  dependencies:
  - build
    Pour ceux qui lisent ce commentaire, vous devez d'ABORD configurer votre machine pour le coureur. Suivez le guide de Prasanth Louis-dessous, et en particulier le lien gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/... (parce qu'il y avait des mises à jour). Alors seulement, vous pouvez utiliser cette .gitlab-ci.yml.
    Merci de vous y compris. Oui et vous allez avoir besoin de visual studio est installé sur votre machine de compilation que je crois MSTest, en fait partie.
    Veuillez soumettre votre exemple, à la GitLab CI Yml.
    mon projet de construire avec succès, mais supprime tous sans traces de fichiers, y compris nécessaires bin/ dossiers pour les tests.. quelque chose d'étrange avec des artefacts: sans traces: vrai?
    Si ils ne sont pas suivis par git ils doivent être ajoutés comme par docs.gitlab.com/ee/ci/yaml/#artifacts-untracked Si vous archivez des fichiers dll git alors vous allez avoir à modifier ou demandez-vous pourquoi vous n'êtes pas en tirant à partir de pépite.

    OriginalL'auteur Jeff

  2. 20

    Afin de construire une application en C#, vous devriez avoir un Windows Runner (avec la coquille exécuteur testamentaire) configuré pour un projet dans Gitlab CI.

    Votre .gitlab-ci.fichier yml devrait ressembler à quelque chose comme ça:

    stages:
  - build

job:
  stage: build
  script:
  - echo "Restoring NuGet Packages..."
  - '"c:\nuget\nuget.exe" restore "MySolution.sln"'
  - ''
  - echo "Release build..."
  - C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "MySolution.sln"
  tags: 
  except:
  - tags

    Sur la machine Windows, vous avez besoin des outils suivants:

    • coureur installé
    • git, ajouter au CHEMIN
    • dernière nuget.exe au c:\nuget (ou quelque part d'autre, assurez-vous que vous avez obtenu le droit chemin .gitlab-ci.fichier yml)
    Je suis désolé, que voulez-vous dire avec git, ajouté au CHEMIN d'accès'?
    Il a obtenu, c'est pour Windows à savoir où git est situé de sorte que le git peut être exécutée comme shell.
    Votre chemin de msbuild ne fonctionne pas si il y a un espace.
    Sur gitlab.com il n'y a pas partagé windows runner disponible. L'partagé coureur sur gitlab.com a Docker, mais Docker ne supporte pas (encore) de windows conteneurs.* Connaissez-vous des plans de Gitlab soutenir un windows partagé coureur? *) Oui, Docker prend en charge windows conteneurs d'une façon bizarre, mais seulement si Docker client s'exécute sur une machine windows, qui, dans une certaine mesure, défie le but.
    Il y a des instructions d'installation pour windows disponible ici. Il y a des liens vers x86 et amd64 les coureurs. Espérons que cela aide.

    OriginalL'auteur Grisha

  3. 9

    Autres réponses sont bonnes. Mais j'aimerais vous expliquer comment installer un coureur en plus. J'utilise mon propre système local (Windows), j'ai donc choisi d'exécuter un shell. Mais vous pouvez utiliser un menu fixe de l'image si vous le souhaitez.

    cd C:\Multi-Runner
gitlab-ci-multi-runner register

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
shell
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!

    Source : https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/windows.md

    Par la suite, vous pouvez utiliser un fichier yml un comme ceci:

    stages:
    - build
job:
    stage: build
    script: '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "something.sln"'
    Veuillez soumettre votre exemple, à la GitLab CI Yml.

    OriginalL'auteur Prasanth Louis

  4. 8

    Qui arrivent en retard à ce que je sais, mais je voulais étendre sur cette même plus.

    L'installation du coureur sur une machine windows aide beaucoup, @prasanth-louis a un très bon exemple sur la façon de le faire.

    Comme pour le .gitlab-ci.yml vous pouvez simplifier encore plus en utilisant Gâteau De Construire

    stages:
    - build
build:
    stage: build
    script: 
        - .\build.ps1 -Target Build
    tags:
        - windows

    Et votre build.cake fichier peut ressembler à ceci (en fonction de la exemple repo):

    #tool nuget:?package=NUnit.ConsoleRunner&version=3.4.0

var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");

var solution = "./example-project.sln";
var buildDir = Directory("./example-project/bin");

Task("Default")
    .IsDependentOn("Unit-Tests")
    .Does(() => 
{
    Information("Running Default task!");
});

Task("Clean")
    .Does(() =>
{
    CleanDirectory(buildDir);
});

Task("PackageRestore")
    .IsDependentOn("Clean")
    .Does(() =>
{
    Information("Restoring nuget packages for {0}", solution);
    NuGetRestore(solution);
});

Task("Build")
    .IsDependentOn("PackageRestore")
    .Does(() => 
{
    Information("Restoring nuget packages for {0}", solution);
    MSBuild(solution, settings => settings.SetConfiguration(configuration));
});

Task("Unit-Tests")
    .IsDependentOn("Build")
    .Does(() =>
{
    NUnit3("./example-project.Tests/**/bin/" + configuration + "/*.Tests.dll");
});

Task("Publish")
    .Does(() =>
{

});

RunTarget(target);
    Le gâteau est certainement le chemin à parcourir, surtout si vous êtes en transition de TeamCity, Jenkins, etc. serveur qui a traité un grand nombre de ce genre de choses pour vous.

    OriginalL'auteur SolThoth