mirror of
https://gitgud.io/amevarashi/rjw-sexperience-ideology.git
synced 2024-08-15 00:43:19 +00:00
Update .gitlab-ci.yml file
This commit is contained in:
parent
89aefe03fe
commit
3bcc4f334e
1 changed files with 109 additions and 40 deletions
149
.gitlab-ci.yml
149
.gitlab-ci.yml
|
@ -1,49 +1,118 @@
|
|||
# This file is a template, and might need editing before it works on your project.
|
||||
# This is a sample GitLab CI/CD configuration file that should run without any modifications.
|
||||
# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
|
||||
# it uses echo commands to simulate the pipeline execution.
|
||||
#
|
||||
# A pipeline is composed of independent jobs that run scripts, grouped into stages.
|
||||
# Stages run in sequential order, but jobs within stages run in parallel.
|
||||
#
|
||||
# For more information, see: https://docs.gitlab.com/ee/ci/yaml/index.html#stages
|
||||
#
|
||||
# You can copy and paste this template into a new `.gitlab-ci.yml` file.
|
||||
# You should not add this template to an existing `.gitlab-ci.yml` file by using the `include:` keyword.
|
||||
#
|
||||
# To contribute improvements to CI/CD templates, please follow the Development guide at:
|
||||
# https://docs.gitlab.com/ee/development/cicd/templates.html
|
||||
# This specific template is located at:
|
||||
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Getting-Started.gitlab-ci.yml
|
||||
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml
|
||||
|
||||
stages: # List of stages for jobs, and their order of execution
|
||||
- build
|
||||
- test
|
||||
- deploy
|
||||
# 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/_/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: mcr.microsoft.com/dotnet/sdk:latest
|
||||
|
||||
build-job: # This job runs in the build stage, which runs first.
|
||||
# ### 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 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:
|
||||
#
|
||||
# 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 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:
|
||||
- echo "Compiling the code..."
|
||||
- echo "Compile complete."
|
||||
- 'dotnet build --no-restore'
|
||||
|
||||
unit-test-job: # This job runs in the test stage.
|
||||
stage: test # It only starts when the job in the build stage completes successfully.
|
||||
script:
|
||||
- echo "Running unit tests... This will take about 60 seconds."
|
||||
- sleep 60
|
||||
- echo "Code coverage is 90%"
|
||||
#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'
|
||||
|
||||
lint-test-job: # This job also runs in the test stage.
|
||||
stage: test # It can run at the same time as unit-test-job (in parallel).
|
||||
script:
|
||||
- echo "Linting code... This will take about 10 seconds."
|
||||
- sleep 10
|
||||
- echo "No lint issues found."
|
||||
|
||||
deploy-job: # This job runs in the deploy stage.
|
||||
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
|
||||
environment: production
|
||||
script:
|
||||
- echo "Deploying application..."
|
||||
- echo "Application successfully deployed."
|
||||
#deploy:
|
||||
# stage: deploy
|
||||
# script: echo "Define your deployment script!"
|
||||
# environment: production
|
||||
|
|
Loading…
Reference in a new issue