Skip to content

Latest commit

 

History

History
84 lines (52 loc) · 4.39 KB

gitlab.md

File metadata and controls

84 lines (52 loc) · 4.39 KB
Raw

Part 1 (GitLab CI)

Using shared runners on GitLab.com, which we will do today, requires account validation with a credit/debit card.

Step 1 - Get the code

  • Sign in to GitLab and create a new project/repository
  • Select "Import project"
  • Select "Repo by URL"
  • Enter the URL of this repository and omit any username/password (credentials aren't required because this repository is public).

Finish creating the project and then you should be able to clone your new repository.

Step 2 - Set up the app

Follow the instructions in the Running Locally section to try running the application locally. If you encounter issues running the app locally, feel free to skip to step 3 instead of spending time resolving the issues. The only benefit of running it locally first is to better understand what you want your pipeline to replicate.

Step 3 - Set up GitLab CI

  1. Create the config file for your continuous integration pipeline:

    • Create a file called .gitlab-ci.yml in the root of the project

  2. Implement a basic workflow:

    stages:
  - test    # This pipeline consists of a single stage called "test"

my-job:         # Start defining a job called "my-job"
  stage: test   # This job belongs to the "test" stage
  script:
    - echo "Hello, world"  # Run a script

  3. Commit and push your changes to a branch on your repository.

  4. On your repository page, navigate to the CI/CD tab.

  5. You should see a table of pipelines. This should have one entry with a name matching your latest commit message. Select this entry.

  6. You should see a page with a visual representation of your pipeline, you can click on a job to see the detailed console output.

If you haven't already, you will need to enter credit card details at this stage to enable use of the shared job runners. GitLab.com will show a notification if this is the case.

See the GitLab documentation for more details on how to get set up GitLab CI/CD and https://docs.gitlab.com/ee/ci/yaml/index.html for more details on the syntax of the gitlab-ci.yml file.

Step 4 - Implement the CI pipeline

Validate the C# code

First, we want the CI pipeline to build the C# code and run the C# tests. This requires having the .NET SDK installed. Instead of scripting the installation of .NET on the runner, we can run the job inside a container that already has it installed. To do this, add image: desired-image-name-here to your job, but with an appropriate image name. Find the correct tag for Microsoft's image.

Amend the job in your workflow file so that it:

  1. Uses a Docker image that has the .NET SDK installed
  2. Builds the C# code.
  3. Runs the C# tests.

Update the script to run the two commands dotnet build and dotnet test. Push your changes and check that the pipeline succeeds.

Validate the TypeScript code

Next, we want the pipeline to validate the TypeScript code. You need a different image (with Node installed instead of .NET) so create a second job with an appropriate image. This new job can belong to the same stage as the first one, because they do not depend on each other and can happily run in parallel.

Fill in the "script" section with the correct commands so that it:

  1. Uses a Docker image with Node installed
  2. Installs dependencies and build the TypeScript code.
  3. Runs the linter on the TypeScript code.
  4. Runs the TypeScript tests.

Remember that you want to run the npm commands from the DotnetTemplate.Web directory.

(Stretch goal) Slack notifications

To make sure people are aware when there are issues with the build, it can be useful to send a Slack notification at the end of the workflow.

Before attempting this step please create your own personal slack workspace. This is free and can be set up here.

Take a look at the GitLab Slack integration.

(Stretch goal) Pipeline status badge

Add a pipeline status badge to your repository.

(Stretch goal) Change when the workflow is run

Change your workflow so that it only runs when pushing to the main branch or by raising a Merge Request. Is there a way to ensure that no one can update the main branch except through a PR that has passed the workflow?