-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path.gitlab-ci.yml
157 lines (144 loc) · 6.29 KB
/
.gitlab-ci.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
# 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/main/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml
# Note: When updating this template, please consider updating the official CI .NET template at:
# https://gitlab.com/gitlab-org/gitlab-foss/-/blob/main/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml
# 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:8.0
# ### 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: './packages/runtimes/'
# 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:
- CHCP 65001
- 'dotnet restore --packages $NUGET_PACKAGES_DIRECTORY'
build:
tags:
- dotnet8
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 use a separate solution
# file that only has .NET Core-based projects (`dotnet build MyApp.core.sln`),
# or 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 --packages $NUGET_PACKAGES_DIRECTORY'
tests:
tags:
- dotnet8
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 --packages $NUGET_PACKAGES_DIRECTORY'
deploy:
tags:
- dotnet8
stage: deploy
script: echo "Define your deployment script!"
environment: production
# build-job:
# stage: build
# script:
# - echo "Hello, $GITLAB_USER_LOGIN!"
# test-job1:
# stage: test
# script:
# - echo "This job tests something"
# test-job2:
# stage: test
# script:
# - echo "This job tests something, but takes more time than test-job1."
# - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
# - echo "which simulates a test that runs 20 seconds longer than test-job1"
# - sleep 20
# deploy-prod:
# stage: deploy
# script:
# - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
# environment: production
# test-job1:
# stage: test
# script:
# - echo "This job tests something"