Update .NET Core YAML template - improve indent

Improve indent and remove empty lines

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

@@ -13,19 +13,17 @@
 # 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.
+ # 1) Name of directory where restore and build objects are stored.
  OBJECTS_DIRECTORY: 'obj'    
-# 2) Name of directory used for keeping restored dependencies.        
+ # 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!
+ # 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. 
@@ -34,7 +32,6 @@ stages:
  - build
  - test
 
-
 # ### Define global cache rule
 #
 # Before building the project, all dependencies (e.g. third-party NuGet packages) 
@@ -52,28 +49,26 @@ 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.
+ # 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.
+ # 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.
+ # 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.
+ #      
+ # '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 
@@ -86,32 +81,28 @@ cache:
 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.
+ # ### 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.
+ # ### 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'