Skip to content
Snippets Groups Projects
Commit 8d985ef7 authored by splicing3089's avatar splicing3089
Browse files

Cleanup

parent ac5c1d63
No related branches found
No related tags found
No related merge requests found
# 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/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/master/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:7.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: '.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 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'
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'
deploy:
stage: deploy
script: echo "Define your deployment script!"
environment: production
\ No newline at end of file
image: gitpod/workspace-dotnet
tasks:
- init: dotnet build
command: dotnet run
## Introduction
# RJW_Onahole
This is a simple pipeline example for a .NET Core application, showing just
how easy it is to get up and running with .NET development using GitLab.
# Reference links
- [GitLab CI Documentation](https://docs.gitlab.com/ee/ci/)
- [.NET Hello World tutorial](https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/)
If you're new to .NET you'll want to check out the tutorial, but if you're
already a seasoned developer considering building your own .NET app with GitLab,
this should all look very familiar.
## What's contained in this project
The root of the repository contains the out of the `dotnet new console` command,
which generates a new console application that just prints out "Hello, World."
It's a simple example, but great for demonstrating how easy GitLab CI is to
use with .NET. Check out the `Program.cs` and `dotnetcore.csproj` files to
see how these work.
In addition to the .NET Core content, there is a ready-to-go `.gitignore` file
sourced from the the .NET Core [.gitignore](https://github.com/dotnet/core/blob/master/.gitignore). This
will help keep your repository clean of build files and other configuration.
Finally, the `.gitlab-ci.yml` contains the configuration needed for GitLab
to build your code. Let's take a look, section by section.
First, we note that we want to use the official Microsoft .NET SDK image
to build our project.
```
image: microsoft/dotnet:latest
```
We're defining two stages here: `build`, and `test`. As your project grows
in complexity you can add more of these.
```
stages:
- build
- test
```
Next, we define our build job which simply runs the `dotnet build` command and
identifies the `bin` folder as the output directory. Anything in the `bin` folder
will be automatically handed off to future stages, and is also downloadable through
the web UI.
```
build:
stage: build
script:
- "dotnet build"
artifacts:
paths:
- bin/
```
Similar to the build step, we get our test output simply by running `dotnet test`.
```
test:
stage: test
script:
- "dotnet test"
```
This should be enough to get you started. There are many, many powerful options
for your `.gitlab-ci.yml`. You can read about them in our documentation
[here](https://docs.gitlab.com/ee/ci/yaml/).
## Developing with Gitpod
This template repository also has a fully-automated dev setup for [Gitpod](https://docs.gitlab.com/ee/integration/gitpod.html).
The `.gitpod.yml` ensures that, when you open this repository in Gitpod, you'll get a cloud workspace with .NET Core pre-installed, and your project will automatically be built and start running.
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment