# This is a simple example illustrating how to build and test .NET Core project
# with GitLab Continuous Integration / Continuous Delivery.

# ### Specify the Docker image
#
# 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.
#
# 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
# and the Docker itself: https://opensource.com/resources/what-docker
image: microsoft/dotnet:latest

# ### Define variables
#
variables:
 # 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: '*/*/'             

# ### Define stage list
#
# In this example there are only two stages. 
# Initially, the project will be built and then tested.
stages:
 - build
 - test

# ### 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 it is removed. 
# What that means is 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 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, 
 # 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.
 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.
#
# 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
 # ### 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 
 # 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:
  - 'dotnet build --no-restore' 

tests:
 stage: test
 # ### 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:
 - 'dotnet test --no-restore'