This is how I would do it using Github:
jobs:
run-tests:
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./MyApp
steps:
- uses: actions/checkout@v2
- name: Setup .NET
uses: actions/setup-dotnet@v1
with:
dotnet-version: 5.0.x
- name: Restore dependencies
run: dotnet restore
- name: Build project
run: dotnet build --no-restore
- name: Run tests
run: dotnet test --no-build
This time on Gitlab my project solution file is in the root directory of the repository. I created a .gitlab-ci.yml file and started with
image: mcr.microsoft.com/dotnet/sdk:5.0
stages:
- restore-dependencies
- build-solution
- run-tests
restore-dependencies:
stage: restore-dependencies
script:
- dotnet restore --packages packages
artifacts:
paths:
- packages
build-solution:
stage: build-solution
script:
- dotnet build --no-restore --source packages --output build
artifacts:
paths:
- build
dependencies:
- restore-dependencies
run-tests:
stage: run-tests
script:
- dotnet test --no-build --output build
dependencies:
- build-solution
The first job passes but the second one fails because it can't find the restored files from the first job. So my solution has a TestProject1 and the second job is not able to find a resource file in ...\TestProject1\obj\project.assets.json
How can I fix the pipeline configuration?
You are using separate jobs to run each command. Gitlab runs each job in a new container, destroying any context from the previous command except for explicitly specified artifacts. To run sequential commands like you have configured in Github actions, you can just add multiple steps which will run sequentially in the same image, preserving the context between commands.
stages:
- build-solution
run-tests:
image: mcr.microsoft.com/dotnet/sdk:5.0
stage: build-solution
script:
- dotnet restore
- dotnet build --no-restore
- dotnet test --no-build
Alternatively, you could use artifacts and flags to transfer the output of each command between jobs:
I believe artifacts have to be relative paths to your $CI_PROJECT_DIR (source), and according to the dotnet restore documentation the default write location is in the home directory.
You could try specifying the write location as packages/ with dotnet restore --packages packages (source)
and the read location as packages/ with dotnet build --source packages (source)
Then you would need to specify this artifact like:
artifacts:
paths:
- packages
You would need a similar usage of the --output flag to save your build artifact in the build-solution stage.
This is more complicated, but may be desired in some cases.
This isn't a worthy answer but it might help. I reproduced it and got the same problems. Somehow this worked for me
image: mcr.microsoft.com/dotnet/sdk:5.0
stages:
- build-solution
- run-tests
build-solution:
stage: build-solution
script:
- dotnet build --output build
artifacts:
paths:
- build
run-tests:
stage: run-tests
script:
- dotnet test --no-build --output build
dependencies:
- build-solution
So you might want to forget about the restore stage because it should always build first ...
Maybe it might me worth a try to define the pipeline as a Directed Acyclic Graph (DAG), so instead of defining dependencies in your step, you could define needs. When a Job is defined with the needs keyword it will only start if all dependent previous jobs succeeded (except they are allowed to fail). The advantage of the needs keyword here would be that you can explicitly configure the step to download the artifacts from the previous jobs
image: mcr.microsoft.com/dotnet/sdk:5.0
stages:
- restore-dependencies
- build-solution
- run-tests
restore-dependencies:
stage: restore-dependencies
script:
- dotnet restore --packages packages
artifacts:
paths:
- packages
build-solution:
stage: build-solution
script:
- dotnet build --no-restore --source packages --output build
artifacts:
paths:
- build
needs:
- job: restore-dependencies
artifacts: true
run-tests:
stage: run-tests
script:
- dotnet test --no-build --output build
needs:
- job: build-solution
artifacts: true