Update .gitlab-ci.yml

.gitlab-ci.yml

@@ -1,57 +1,17 @@
----
+---
-# 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: 'ChaosBot/*/'
 
-# ### 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 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:
@@ -64,54 +24,17 @@ cache:
     # 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
 
-# ### 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
-  # ### 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:
     - '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'