Edit comments in CI template

lib/gitlab/ci/templates/dotNET-Core.yml

@@ -3,10 +3,11 @@
 
 # ### 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.
+# 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
@@ -17,16 +18,16 @@ image: microsoft/dotnet:latest
 #
 variables:
  # 1) Name of directory where restore and build objects are stored.
- OBJECTS_DIRECTORY: 'obj'    
- # 2) Name of directory used for keeping restored dependencies.        
+ 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: '*/*/'             
+ SOURCE_CODE_PATH: '*/*/'
 
 # ### Define stage list
 #
-# In this example there are only two stages. 
+# In this example there are only two stages.
 # Initially, the project will be built and then tested.
 stages:
  - build
@@ -34,47 +35,55 @@ stages:
 
 # ### 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 
+# 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 
+# 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" 
+ 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'  
+  - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json'
   # 2) Other NuGet and MSBuild related files. Also needed.
-  - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*'    
+  - '$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 
+  - '$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
 
 # ### 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.
+# 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:
@@ -82,26 +91,26 @@ before_script:
 
 build:
  stage: build
- # ### Build all projects discovered from solution file. 
+ # ### 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'. 
+ # 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:
-  - 'dotnet build --no-restore' 
+  - '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 
+ # 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'