commit a0aa9cc28ed70f9088b55e7c1416c4ba798d99f8 Author: GitLab Date: Fri Dec 16 10:41:27 2022 -0800 Initialized from '.NET Core' project template Template repository: https://gitlab.com/gitlab-org/project-templates/dotnetcore Commit SHA: de5759f7a2f08808666b44eb4fd6205502a9fe75 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..0385ff2 --- /dev/null +++ b/.gitignore @@ -0,0 +1,31 @@ +*.swp +*.*~ +project.lock.json +.DS_Store +*.pyc +nupkg/ + +# Visual Studio Code +.vscode + +# User-specific files +*.suo +*.user +*.userosscache +*.sln.docstates + +# Build results +[Dd]ebug/ +[Dd]ebugPublic/ +[Rr]elease/ +[Rr]eleases/ +x64/ +x86/ +build/ +bld/ +[Bb]in/ +[Oo]bj/ +[Oo]ut/ +msbuild.log +msbuild.err +msbuild.wrn diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml new file mode 100644 index 0000000..79a7aae --- /dev/null +++ b/.gitlab-ci.yml @@ -0,0 +1,120 @@ +# 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 ' 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 diff --git a/.gitpod.yml b/.gitpod.yml new file mode 100644 index 0000000..fef6e10 --- /dev/null +++ b/.gitpod.yml @@ -0,0 +1,5 @@ +image: gitpod/workspace-dotnet + +tasks: + - init: dotnet build + command: dotnet run diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..47ac404 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,40 @@ +## Developer Certificate of Origin and License + +By contributing to GitLab B.V., you accept and agree to the following terms and +conditions for your present and future contributions submitted to GitLab B.V. +Except for the license granted herein to GitLab B.V. and recipients of software +distributed by GitLab B.V., you reserve all right, title, and interest in and to +your Contributions. + +All contributions are subject to the Developer Certificate of Origin and license set out at [docs.gitlab.com/ce/legal/developer_certificate_of_origin](https://docs.gitlab.com/ce/legal/developer_certificate_of_origin). + +_This notice should stay as the first item in the CONTRIBUTING.md file._ + +## Code of conduct + +As contributors and maintainers of this project, we pledge to respect all people +who contribute through reporting issues, posting feature requests, updating +documentation, submitting pull requests or patches, and other activities. + +We are committed to making participation in this project a harassment-free +experience for everyone, regardless of level of experience, gender, gender +identity and expression, sexual orientation, disability, personal appearance, +body size, race, ethnicity, age, or religion. + +Examples of unacceptable behavior by participants include the use of sexual +language or imagery, derogatory comments or personal attacks, trolling, public +or private harassment, insults, or other unprofessional conduct. + +Project maintainers have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct. Project maintainers who do not follow the +Code of Conduct may be removed from the project team. + +This code of conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. + +Instances of abusive, harassing, or otherwise unacceptable behavior can be +reported by emailing contact@gitlab.com. + +This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org), version 1.1.0, +available at [https://contributor-covenant.org/version/1/1/0/](https://contributor-covenant.org/version/1/1/0/). diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..abdb150 --- /dev/null +++ b/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2019- Present GitLab B.V. + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/Program.cs b/Program.cs new file mode 100644 index 0000000..a3388e0 --- /dev/null +++ b/Program.cs @@ -0,0 +1,12 @@ +using System; + +namespace dotnetcore +{ + class Program + { + static void Main(string[] args) + { + Console.WriteLine("Hello World!"); + } + } +} diff --git a/README.md b/README.md new file mode 100644 index 0000000..7d8beb5 --- /dev/null +++ b/README.md @@ -0,0 +1,78 @@ +## Introduction + +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 diff --git a/dotnetcore.csproj b/dotnetcore.csproj new file mode 100644 index 0000000..120e38c --- /dev/null +++ b/dotnetcore.csproj @@ -0,0 +1,8 @@ + + + + Exe + net7.0 + + +