diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 5d065deb23c8a2c7adf2434d499167150abbe1b4..b8d284532bd7afa780cd988dc9357697238de3cd 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,89 +1,113 @@ -# This file is a template, and might need editing before it works on your project. # To contribute improvements to CI/CD templates, please follow the Development guide at: # https://docs.gitlab.com/ee/development/cicd/templates.html # This specific template is located at: -# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml +# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml -# The following script will work for any project that can be built from command line by msbuild -# It uses powershell shell executor, so you need to add the following line to your config.toml file -# (located in gitlab-runner.exe directory): -# shell = "powershell" +# This is a simple example illustrating how to build and test .NET Core project +# with GitLab Continuous Integration / Continuous Delivery. # -# The script is composed of 3 stages: build, test and deploy. +# ### Specify the Docker image # -# The build stage restores NuGet packages and uses msbuild to build the exe and msi -# One major issue you'll find is that you can't build msi projects from command line -# if you use vdproj. There are workarounds building msi via devenv, but they rarely work -# The best solution is migrating your vdproj projects to WiX, as it can be build directly -# by msbuild. +# Instead of installing .NET Core SDK manually, a docker image is used +# with already pre-installed .NET Core SDK. # -# The test stage runs nunit from command line against Test project inside your solution -# It also saves the resulting TestResult.xml file +# The 'latest' tag targets the latest available version of .NET Core SDK image. +# If preferred, you can explicitly specify version of .NET Core (e.g. using '2.2-sdk' tag). # -# The deploy stage copies the exe and msi from build stage to a network drive -# You need to have the network drive mapped as Local System user for gitlab-runner service to see it -# The best way to persist the mapping is via a scheduled task -# running the following batch command: net use P: \\x.x.x.x\Projects /u:your_user your_pass /persistent:yes +# See other available tags for .NET Core: https://hub.docker.com/_/microsoft-dotnet +# Learn more about Docker tags: https://docs.docker.com/glossary/?term=tag +# and the Docker itself: https://opensource.com/resources/what-docker +image: mcr.microsoft.com/dotnet/sdk:latest -# place project specific paths in variables to make the rest of the script more generic +# ### Define variables +# variables: - EXE_RELEASE_FOLDER: 'YourApp\bin\Release' - MSI_RELEASE_FOLDER: 'Setup\bin\Release' - TEST_FOLDER: 'Tests\bin\Release' - DEPLOY_FOLDER: 'P:\Projects\YourApp\Builds' - NUGET_PATH: 'C:\NuGet\nuget.exe' - MSBUILD_PATH: 'C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe' - NUNIT_PATH: 'C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe' + # 1) Name of directory where restore and build objects are stored. + OBJECTS_DIRECTORY: 'obj' + # 2) Name of directory used for keeping restored dependencies. + NUGET_PACKAGES_DIRECTORY: '.nuget' + # 3) A relative path to the source code from project repository root. + # NOTE: Please edit this path so it matches the structure of your project! + SOURCE_CODE_PATH: '*/*/' -stages: - - build - - test - - deploy +# ### Define global cache rule +# +# Before building the project, all dependencies (e.g. third-party NuGet packages) +# must be restored. Jobs on GitLab.com's Shared Runners are executed on autoscaled machines. +# +# Each machine is used only once (for security reasons) and after that is removed. +# This means that, before every job, a dependency restore must be performed +# because restored dependencies are removed along with machines. Fortunately, +# GitLab provides cache mechanism with the aim of keeping restored dependencies +# for other jobs. +# +# This example shows how to configure cache to pass over restored +# dependencies for re-use. +# +# With global cache rule, cached dependencies will be downloaded before every job +# and then unpacked to the paths as specified below. +cache: + # Per-stage and per-branch caching. + key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG" + paths: + # Specify three paths that should be cached: + # + # 1) Main JSON file holding information about package dependency tree, packages versions, + # frameworks etc. It also holds information where to the dependencies were restored. + - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json' + # 2) Other NuGet and MSBuild related files. Also needed. + - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*' + # 3) Path to the directory where restored dependencies are kept. + - '$NUGET_PACKAGES_DIRECTORY' + # + # 'pull-push' policy means that latest cache will be downloaded (if it exists) + # before executing the job, and a newer version will be uploaded afterwards. + # Such a setting saves time when there are no changes in referenced third-party + # packages. + # + # For example, if you run a pipeline with changes in your code, + # but with no changes within third-party packages which your project is using, + # then project restore will happen quickly as all required dependencies + # will already be there — unzipped from cache. + + # 'pull-push' policy is the default cache policy, you do not have to specify it explicitly. + policy: pull-push -build_job: +# ### Restore project dependencies +# +# NuGet packages by default are restored to '.nuget/packages' directory +# in the user's home directory. That directory is out of scope of GitLab caching. +# +# To get around this, a custom path can be specified using the '--packages <PATH>' option +# for 'dotnet restore' command. In this example, a temporary directory is created +# in the root of project repository, so its content can be cached. +# +# Learn more about GitLab cache: https://docs.gitlab.com/ee/ci/caching/index.html +before_script: + - 'dotnet restore --packages $NUGET_PACKAGES_DIRECTORY' + +build: stage: build - only: - - tags # the build process will only be started by git tag commits + # ### Build all projects discovered from solution file. + # + # Note: this will fail if you have any projects in your solution that are not + # .NET Core-based projects (e.g. WCF service), which is based on .NET Framework, + # not .NET Core. In this scenario, you will need to build every .NET Core-based + # project by explicitly specifying a relative path to the directory + # where it is located (e.g. 'dotnet build ./src/ConsoleApp'). + # Only one project path can be passed as a parameter to 'dotnet build' command. script: - - '& "$env:NUGET_PATH" restore' # restore Nuget dependencies - - '& "$env:MSBUILD_PATH" /p:Configuration=Release' # build the project - artifacts: - expire_in: 1 week # save gitlab server space, we copy the files we need to deploy folder later on - paths: - - '$env:EXE_RELEASE_FOLDER\YourApp.exe' # saving exe to copy to deploy folder - - '$env:MSI_RELEASE_FOLDER\YourApp Setup.msi' # saving msi to copy to deploy folder - - '$env:TEST_FOLDER\' # saving entire Test project so NUnit can run tests + - 'dotnet build --no-restore' -test_job: +tests: stage: test - only: - - tags + # ### Run the tests + # + # You can either run tests for all test projects that are defined in your solution + # with 'dotnet test' or run tests only for specific project by specifying + # a relative path to the directory where it is located (e.g. 'dotnet test ./test/UnitTests'). + # + # You may want to define separate testing jobs for different types of testing + # (e.g. integration tests, unit tests etc). script: - - '& "$env:NUNIT_PATH" ".\$env:TEST_FOLDER\Tests.dll"' # running NUnit tests - artifacts: - when: always # save test results even when the task fails - expire_in: 1 week # save gitlab server space, we copy the files we need to deploy folder later on - paths: - - '.\TestResult.xml' # saving NUnit results to copy to deploy folder - dependencies: - - build_job - -deploy_job: - stage: deploy - only: - - tags - script: - # Compose a folder for each release based on commit tag. - # Assuming your tag is Rev1.0.0.1, and your last commit message is 'First commit' - # the artifact files will be copied to: - # P:\Projects\YourApp\Builds\Rev1.0.0.1 - First commit\ - - '$commitSubject = git log -1 --pretty=%s' - - '$deployFolder = $($env:DEPLOY_FOLDER) + "\" + $($env:CI_BUILD_TAG) + " - " + $commitSubject + "\"' - - # xcopy takes care of recursively creating required folders - - 'xcopy /y ".\$env:EXE_RELEASE_FOLDER\YourApp.exe" "$deployFolder"' - - 'xcopy /y ".\$env:MSI_RELEASE_FOLDER\YourApp Setup.msi" "$deployFolder"' - - 'xcopy /y ".\TestResult.xml" "$deployFolder"' - dependencies: - - build_job - - test_job + - 'dotnet test --no-restore'