kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Edit comments in CI template

Browse source
This commit is contained in:
Evan Read 2019-05-17 08:45:23 +00:00 committed by Grzegorz Bizon
parent 9112f3b492
commit 43d21b831a
1 changed files with 50 additions and 41 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
lib/gitlab/ci/templates/dotNET-Core.yml
View file

@ -5,8 +5,9 @@
#
# Instead of installing .NET Core SDK manually, a docker image is used
# with already pre-installed .NET Core SDK.
#
# 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.
# If preferred, you can explicitly specify version of .NET Core (e.g. using '2.2-sdk' tag).
#
# See other available tags for .NET Core: https://hub.docker.com/r/microsoft/dotnet
# Learn more about Docker tags: https://docs.docker.com/glossary/?term=tag
@ -36,11 +37,14 @@ stages:
#
# 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 it is removed.
# What that means is that before every job a dependency restore must be performed
#
# 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
# 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
@ -58,23 +62,28 @@ cache:
- '$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 exists)
#
# '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 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,
# 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 in next to no time as all required dependencies
# will already be there — unzipped from cache. 'pull-push' policy is a default
# cache policy, you do not have to specify it explicitly.
# 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
# ### 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 '--packages <PATH>' option
# for 'dotnet restore' command. In this example a temporary directory is created
# in the root of project repository, so it's content can be cached.
#
# 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:
@ -85,10 +94,10 @@ build:
# ### 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 such scenario you will need to build every .NET Core based
# .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'.
# 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:
- 'dotnet build --no-restore'
@ -99,9 +108,9 @@ 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'.
# 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.
# (e.g. integration tests, unit tests etc).
script:
- 'dotnet test --no-restore'