Have a yaml file build script and all works fine except for the unit test which fails after various warnings eventually raising MSB3027 and MSB3021 errors.
This is in a pipeline in Atlassian.
Seen issues mentioning long PATH names but how to resolve here? Have similar pipelines setup and working before.
image: mcr.microsoft.com/dotnet/core/sdk:3.1
pipelines:
branches:
develop:
- step:
name: Build and Test
caches:
- dotnetcore
script:
- export ENV_NAME=develop
- export PROJECT_NAME=Myapi
- export ZIP_FILE=Myapi-dev.zip
- export TEST_PROJECT=Myapi.Tests
- dotnet build $PROJECT_NAME
- dotnet test $TEST_PROJECT --no-build --configuration Release
# this will publish our app output into a subfolder so that we can package it up
- dotnet publish $PROJECT_NAME --output $ENV_NAME/publish --configuration release
/usr/share/dotnet/sdk/3.1.402/Microsoft.Common.CurrentVersion.targets(4364,5):
warning MSB3026: Could not copy "/root/.nuget/packages/microsoft.testplatform.objectmodel/16.7.1/lib/netstandard2.0/pt-BR/Microsoft.TestPlatform.CoreUtilities.resources.dll"
to "bin/Release/netcoreapp3.1/pt-BR/Microsoft.TestPlatform.CoreUtilities.resources.dll". Beginning retry 1 in 1000ms.
Could not find a part of the path '/opt/atlassian/pipelines/agent/build/myapi/bin/Release/netcoreapp3.1/pt-BR/Microsoft.TestPlatform.CoreUtilities.resources.dll'.
In the end this was a third party component and the resource file the Test project needed was not in the expected location for the build pipeline. I worked around the issue by copying the files it needed into the target location.
# Workaround for resource file case sensitivity issue
- ls -lR .
- cp -R ./Myapi/bin ./Myapi.Tests/bin
- cp -R ./Myapi/bin/Debug/netcoreapp3.1/pt-br ./Myapi.Tests/bin/Debug/netcoreapp3.1/pt-BR
- dotnet test $TEST_PROJECT
Related
I'm facing trouble with my GitLab CI. The expected workflow for my Test stage is :
fetching changes
checking out
downloading artifacts
run dotnet test
uploading artifacts
The current workflow is :
fetching changes
checking out (removing all bin/obj folder)
uploading artifacts -> this line failed due to inexistance of my test-results.xml file
My solution looks like this:
-- yml file
-- MyApp
-- MyApp.Tests
The version of my gitlab-runner is 12.4.1 and I'm using the shell executor on Windows environment.
Please find below my yml file:
image: mcr.microsoft.com/dotnet/core/sdk:3.1
variables:
EXE_RELEASE_FOLDER: 'Oncolin.UI.Desktop\bin\Release'
# the folder inside the deploy folder
DEPLOY_FOLDER_APP: 'Oncolin.UI.Desktop\Builds'
CONFIGURATION: 'release'
#NUGET_PATH: 'C:\NuGet\nuget.exe'
#MSBUILD_PATH: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe'
#MSTEST_PATH: 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\MSTest.exe'
NUNIT_PATH: '.\packages\NUnit.ConsoleRunner.3.9.0\tools\nunit3-console.exe'
SOLUTION: 'Oncolin.sln'
stages:
- build
- test
build:
stage: build
tags:
- windows
script:
- '& nuget restore' # restore Nuget dependencies
- '& dotnet restore'
- '& SonarScanner.MSBuild.exe begin /k:Oncolin /d:sonar.host.url=https://docker:10500 '
- '& dotnet build -c release'
- '& "$env:MSBUILD_PATH" "$env:SOLUTION" /t:Build /p:Configuration=Release' # build the project
- '& SonarScanner.MSBuild.exe end'
artifacts:
expire_in: 1 week # save gitlab server space, we copy the files we need to deploy folder later on
paths:
- '$env:EXE_RELEASE_FOLDER\*' # saving exe to copy to deploy folder
- 'RNC.RULES.QUALITY.TESTS\*' # saving entire Test project so NUnit can run tests
- 'RNC.MODEL.TNM.TESTS\*' # saving entire Test project so NUnit can run tests
- 'Oncolin.Model.Tests\*' # saving entire Test project so NUnit can run tests
test:
stage: test
tags:
- windows
allow_failure: false
script:
- '& dotnet test --test-adapter-path:. --logger:"junit;LogFilePath=$CI_PROJECT_DIR\artifacts\{assembly}-test-result.xml;MethodFormat=Class;FailureBodyFormat=Verbose"'
artifacts:
expire_in: 1 week # save gitlab server space, we copy the files we need to deploy folder later on
when: always
paths:
- $CI_PROJECT_DIR\artifacts\*test-result.xml
reports:
junit:
- $CI_PROJECT_DIR\artifacts\*test-result.xml
dependencies:
- build
Can someone explain to me why the downloading and dotnet test steps are skipped ? I hope I gave enough informations.
Thanks in advance.
The issue came from the sonar scanner. Even if I used the .Net Core sonar scanner, I had the same issue during my test stage.
I don't know why and I have already lost too many time to investigate on that.
I resolved it by creating a new stage specificly to run the sonar and ran it after the test stage.
I am new to CI and tried to add the following yaml to our project.
image: microsoft/dotnet:latest
stages:
- test
test:
stage: test
before_script:
- 'echo Stage - Test started'
- 'dotnet tool install dotnet-reportgenerator-globaltool --tool-path tools'
script:
- 'cd "./My Project"'
- 'dotnet test --settings:./Settings/CodeCoverage.runsettings --collect:"XPlat Code Coverage"'
- './tools/reportgenerator "-reports:./Tests/*/TestResults/*/coverage.cobertura.xml" "-targetdir:Reports_Coverage" -reportTypes:TextSummary'
- 'cat ./Reports_Coverage/Summary.txt'
after_script:
- 'echo Stage - Test finished'
On the job I get the following output:
Running with gitlab-runner 13.7.0 (943fc252) on ***
Resolving secrets
Preparing the "kubernetes" executor
Using Kubernetes namespace: gitlab-pipeline
Using Kubernetes executor with image microsoft/dotnet:latest ...
Preparing environment
Running on*** via ***...
Getting source from Git repository
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/***/.git/
Created fresh repository.
Checking out 07e98444 as ***...
Skipping Git submodules setup
Executing "step_script" stage of the job script
$ echo Stage - Test started
Stage - Test started
$ dotnet tool install dotnet-reportgenerator-globaltool --tool-path tools
You can invoke the tool using the following command: reportgenerator
Tool 'dotnet-reportgenerator-globaltool' (version '4.8.4') was successfully installed.
$ cd "./My Project"
$ dotnet test --settings:./Settings/CodeCoverage.runsettings --collect:"XPlat Code Coverage"
Running after_script
Running after script...
$ echo Stage - Test finished
Stage - Test finished
Cleaning up file based variables
ERROR: Job failed: command terminated with exit code 1
I tinkered around a little bit and realized, that this minified yaml also fails:
image: microsoft/dotnet:latest
stages:
- test
test:
stage: test
before_script:
- 'cd "./My Project"'
- 'dotnet restore'
script:
- 'dotnet test --no-restore'
This generates an equal output, except it stops at dotnet restore.
I honestly don't know what to do, since this is the most minified version of a test I found.
Did I mess up something within the project, or is the problem within the GitLab Runner itself?
Project Version: .net Core App 3.1
Not a real solution, but I found the issue behind this. You can set the verbosity level of the dotnet test command (documentation). While doing so, I found out that you obviously cannot run a WPF project within a Linux based GitLab Runner.
I am trying to add a pipeline to my project. The project is a AWS Lambda written in dotnet. I want to build a pipeline so that it is deployed to AWS whenever I update the code of my Lambda. Here is my code for the pipeline:
image: mcr.microsoft.com/dotnet/core/sdk:3.1
stages:
- build
- deploy
- production
before_script:
- apt update
- apt-get -y install zip
- export PATH="$PATH:/root/.dotnet/tools"
- dotnet tool install -g Amazon.Lambda.Tools
build:
stage: 'build'
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- echo `aws ecr get-login --no-include-email --region $AWS_DEFAULT_REGION` | sh
- dotnet nuget add source url
- dotnet restore
- cd SmoothRunningsAuth
- dotnet lambda package -o publish/$CI_PIPELINE_ID.zip
when: always
artifacts:
name: "$CI_JOB_NAME"
paths:
- project/publish/$CI_PIPELINE_ID.zip
I have tested all of these commands locally and they work fine when I build the package. dotnet nuget add source url is required as I am using packages from a private repository I am using.
However when I push this to GitLab it returns the following errors:
I am not sure why this is happening, it runs all the other dotnet commands fine and this is the command I use when I am trying to add sources.
I am attempting to create a gitlab CI/CD pipeline that includes automated Cypress tests on a .NETcore project. I have a collection of cypress tests that I can successfully run locally. They are stored in the directory:
<project>/Cypress/integration/
My Gitlab CI/CD pipeline is successfully deploying and building the
code on my testing server (Windows Server 2012). However, after deployment the cypress folder is not present on my testing server. However, when I build the project locally there is a cypress folder. In both my local build and the build defined by the gitlab-ci.yaml, the build command is the same:
dotnet publish -c Release
That said, during local builds, the content in my /bin/Release/netcoreapp2.1.publish/cypress does not include my locally created tests- just the examples provided by cypress. The restoring of the node packages is obviously creating a new cypress install.
How can I get my local cypress tests onto my testing server? Any why does the build done via Gitlab CI/CD and my local build differ in whether cypress gets installed?
I have tried updating my .csproj file to include the cypress directory in the build like so:
<ItemGroup>
<!-- include cypress tests in build for automated testing-->
<Content Include="cypress\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
But this gives me an error:
... error NETSDK1022: Duplicate 'Content' items were included...
Any suggestions on how to get this working? Below I am including my gitlab-ci.yaml file:
stages:
- build
- test
- deploy
build:
stage: build
tags:
- cris .netcore
script:
- echo "removing old files"
- 'Remove-Item -path D:\DeployedWebApps\cris-automated-tst\* -recurse'
- echo "dotnet build started"
- 'dotnet publish -c Release -o "D:\DeployedWebApps\cris-automated-tst\"'
test:
stage: test
tags:
- cris .netcore
script:
- echo "testing"
- 'npx cypress run'
deploy:
stage: deploy
tags:
- cris .netcore
script:
- echo "deploying"
when: on_success
environment:
name: Development
url: https://cris-automated-tst.gisdata.mn.gov
only:
- dev
Looks like I solved this on my own. The trick was to publish just the Cypress Integration folder rather than the whole Cypress directory:
<ItemGroup>
<!-- include cypress tests in build for automated testing-->
<Content Include="cypress\integration\**">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
I am getting started with azure-pipelines.yml
I wanted to have 2 jobs within the same stage. One to build a solution and the other to run unit tests.
The problem is that the second job executed a script step and it does not find a folder Release that the previous one should have created:
trigger:
- master
pool:
vmImage: 'ubuntu-18.04'
stages:
- stage: CI
jobs:
- job: Build
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
- script: dotnet build --configuration Release --no-restore
- job: UnitTests
dependsOn: Build
steps:
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
However if I add all the steps within the same job it works:
trigger:
- master
pool:
vmImage: 'ubuntu-18.04'
stages:
- stage: CI
jobs:
- job: Build
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
- script: dotnet build --configuration Release --no-restore
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
I cannot find an answer on why a dependent job cannot find on the file system the folders that a previous one has generated. Any explanation or link to something that clarifies that would be much appreciated.
I have used gitlab in the past and I don't recall a similar behavior although I don't know whether it had the concept of job as a different thing to steps.
The key element that you are missing is that jobs run on independent agents (separate computers) and do not have any kind of shared filesystem.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml
Any files created in one job that you want to make available on a dependent job must be explicitly staged (in job 'A') and then explicitly downloaded (in job 'B').
See publish:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-build-artifacts?view=azure-devops
And download:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-build-artifacts?view=azure-devops