We are running a local azure devops server. Since the last microsoft patch day the dotnet test fails:
When i start the dotnet test on the server direct the dotnet test fails with the same csproj-file. Do i start the dotnet test without specifying the csproj-file, but in the same folder, it runs and the tests succeed. When i start the command line from visual studio tools it runs. Any ideas?
And here is the YAML:
steps:
task: DotNetCoreCLI#2
displayName: 'dotnet test '
inputs:
command: test
projects: |
**/Test.csproj
arguments: '-c Release'
testRunTitle: 'Test'
enabled: false
continueOnError: true
Related
I am trying to publish a Blazor net core app using Azure Pipelines, but I constantly get a 500 error on the Web Deployment stage.
Once the pipeline runs I check through Kudu console and the only two files on the server are an empty web.config and FAILED TO INITIALIZE RUN FROM PACKAGE.txt with Run From Package Initialization failed. inside.
Below is the YAML of the pipeline.
pool:
name: Azure Pipelines
#Your build pipeline references an undefined variable named ‘Parameters.RestoreBuildProjects’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972
#Your build pipeline references the ‘BuildConfiguration’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: restore
projects: '$(Parameters.RestoreBuildProjects)'
feedsToUse: config
nugetConfigPath: NuGet.Config
- task: DotNetCoreCLI#2
displayName: Publish
inputs:
command: publish
publishWebProjects: false
projects: '**/TPL/Server/TPL.Server.csproj'
arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
modifyOutputPath: false
- task: AzureRmWebAppDeployment#4
displayName: 'Azure App Service Deploy: tpl'
inputs:
azureSubscription: '**hidden**'
WebAppName: tpl
deployToSlotOrASE: true
ResourceGroupName: TPL
SlotName: test
packageForLinux: '$(build.artifactstagingdirectory)/**/*.zip'
Deleting and recreating the slot fixed this. I previously had old way CI (from portal's deployment center menu) and my hunch is that didn't get disconnected properly or something like that didn't get cleaned up.
I am a newby with Azure devops.
I want to use an artifact which is build by a devops build pipeline. But devops is mainly for deploying to Microsoft Azure deployments I guess. At least I can't get this simple job done in cmd line.
This is my build pipeline very basic, this produces a Java Maven jar as build artifact.
variables:
MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'
pool:
vmImage: ubuntu-latest
steps:
- task: Maven#3
inputs:
mavenPomFile: 'pom.xml'
mavenOptions: '-Xmx3072m'
javaHomeOption: 'JDKVersion'
jdkVersionOption: '1.8'
jdkArchitectureOption: 'x64'
publishJUnitResults: false
#testResultsFiles: '**/surefire-reports/TEST-*.xml'
goals: 'package'
the resulting artifact of this must be used in a commandline script.
I tried to grep the artifact but that is not possible. I have added the artifacts in the release pipeline in the UI I have created a stage but when I use a Download build artifact
steps:
- task: DownloadBuildArtifacts#1
displayName: 'Download Build Artifacts'
inputs:
buildType: specific
project: '149ff8df-e61a-446b-ab03-aa0d83882197'
pipeline: 5
downloadType: specific
and the Command line script:
steps:
- script: |
echo Write your commands here
echo Hello world
git version
echo start
echo $(RELEASE.ARTIFACTS._MULE-SHARED-RESOURCES.BUILDNUMBER)
echo $(Release.Artifacts._MULE-SHARED-RESOURCES.BuildNumber)
mvn --version
echo stop
cd /home/vsts/work/r1/a
ls -la
echo afterdir
cd $(System.ArtifactsDirectory)
ls -la
echo afterdir1
pwd
#npm install
cd $(Pipeline.Workspace)
cd work
ls -la
echo afterdir2
cd /
displayName: 'Command Line Script'
How to find my artifacts ?
i'm setting up a pipeline for asp.net application. During integration tests task i need to connect to a SQL server. How can i say to the pipeline that i need a sql service ?
I have tried with multiple microsoft hosted agent pool (Windows Server 1803, Hosted 2017 & 2019)
I use Windows Server 1803 and issue is:
The operating system of the container does not match the operating system of the host.
I would like setting up correctly a temporaly sql server to running tests.
I have used localdb instead.
i run this script before my intregration tests task
SqlLocalDB.exe create "DeptLocalDB"
SqlLocalDB.exe share "DeptLocalDB" "DeptSharedLocalDB"
SqlLocalDB.exe start "DeptLocalDB"
SqlLocalDB.exe info "DeptLocalDB"
To connect with powershell: Invoke-Sqlcmd -Query "SELECT GETDATE() AS TimeOfQuery;" -ServerInstance "(localdb)\.\DeptSharedLocalDB"
To connect with sqlcmd: sqlcmd -S (localdb)\.\DeptSharedLocalDB
To connect a c# app (connectionString): "Data Source=(localdb)\.\DeptS
haredLocalDB;Initial Catalog=DeptLocalDB;Integrated Security=True;"
If someone know how to mount a sql server in a container on azure pipeline, it will be appreciated. Thank for reading
Chocolatey is installed on windows-latest.
So, if you in you YAML file define:
pool:
vmImage: windows-latest
you can then install SQL Server Express using choco:
- script: choco install sql-server-express
azure-pipelines.yml:
pool:
vmImage: 'windows-latest'
...
- task: PowerShell#2
displayName: 'start mssqllocaldb'
inputs:
targetType: 'inline'
script: 'sqllocaldb start mssqllocaldb'
After the following connection string is valid:
Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=my-db;Integrated Security=True;
Source:
https://www.jannikbuschke.de/blog/azure-devops-enable-mssqllocaldb/
In my case (some .NET Core integration tests that needed LocalDB), just using the windows-latest image did the job:
pool:
vmImage: 'windows-latest'
The image comes with Visual Studio which includes LocalDB.
Here a full example of how I achieved running Integration tests using Sql Express in Azure Devops. I had to use the YAML based pipelines so I could use simonauner's approach using Chocolatey to install Sql Express. Make note that I had to install EF Core tools since I use .Net Core 3.1 in this pipeline. Also note that I generate an EF Code First migration SQL file on the fly so that the rigged SQL Express instance is filled with contents.
Deploy SQL Express instance in Azure Devops, install and generate and run EF Code first migration sql script to update database with schema and seed data using EF Code First tools.
# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- feature/testability
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- script: choco install sql-server-express
- task: NuGetToolInstaller#1
- task: VisualStudioTestPlatformInstaller#1
displayName: 'Visual Studio Test Platform Installer'
inputs:
versionSelector: latestStable
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration Debug' # Update this to match your need
- script: 'dotnet tool install --global dotnet-ef'
displayName: 'Generate EF Code First Migrations SQL Script Update script'
- script: 'dotnet ef migrations script -i -o %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql --project .\SomeAcme\SomeAcme.csproj'
displayName: 'Generate EF Code First Migrations migrate.sql'
- script: 'sqlcmd -S .\SQLEXPRESS -Q "CREATE DATABASE [SomeAcmeDb]"'
displayName: 'Create database SomeAcmeDb in Azure Devops SQL EXPRESS'
- script: 'sqlcmd -i %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql -S .\SQLEXPRESS -d SomeAcmeDb'
displayName: ' Run migrate.sql on SQL EXPRESS in Azure Devops'
# PowerShell
# Run a PowerShell script on Linux, macOS, or Windows
- task: PowerShell#2
inputs:
targetType: 'inline' # Optional. Options: filePath, inline
#filePath: # Required when targetType == FilePath
#arguments: # Optional
script: 'gci -recurse -filter *.dll' # Required when targetType == Inline
#errorActionPreference: 'stop' # Optional. Options: stop, continue, silentlyContinue
#failOnStderr: false # Optional
#ignoreLASTEXITCODE: false # Optional
#pwsh: false # Optional
#workingDirectory: # Optional
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
inputs:
testAssemblyVer2: |
**\*SomeAcme.Tests.dll
!**\*TestAdapter.dll
!**\obj\**
vsTestVersion: toolsInstaller
testFiltercriteria: 'Category=IntegrationTest'
runInParallel: false
codeCoverageEnabled: false
testRunTitle: 'XUnit tests SomeAcme solution integration test starting'
failOnMinTestsNotRun: true
rerunFailedTests: false
I need localdb in order to run database unit tests, and I also require at least SQL Server 2016 SP2 because my team is using some of the newer language features.
On a windows-2019 image, simply use choco or powershell to execute the following command:
choco upgrade sqllocaldb
Added a Publish test results task in Azure DevOpsCI/CD pipeline, test were successfull, but after running the test it complaints about ##[warning]No test result files matching **/test-*.xml were found. Could someone please advise on how can we resolve similar problem ?
Publish Test Results task : configuration
Test result format= JUnit
Test results files= **/test-*.xml
Search folder = $(System.DefaultWorkingDirectory)
Test results title = Cypress Test Results
note: I have try adding the search folder path as follows: C:\agent_work\r5\a\drop\ui-tests\cypress
package.json to run the tests
"scripts": {
"test": "cypress run --record --key <key value here>"
}
My directory path in server:
C:\agent_work\r5\a\drop\ui-tests\cypress
My friend, I was facing the same issue on Azure DevOps.
In my case, the folder where the xml files were generated was reports on the root of the repo, that depends on how you got configured Junit on your cypress.json file
So In my case, the solution was changing this on azure-pipelines.yml
testResultsFiles: "results/*.xml"
searchFolder: $(System.DefaultWorkingDirectory)
So that's the entire setup of the testing pipeline
# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
displayName: 'Install Node.js'
- script: "npm i"
displayName: "Install project dependencies"
- script: "npm run cy:verify"
displayName: "Cypress Verify"
- script: "source cypress.env" # comment this script to run tests against production
displayName: "Using env variables to change url to test against development branch"
- script: "npm run cy:run-report"
displayName: "Run Cypress Tests"
- task: PublishBuildArtifacts#1
displayName: "Publish Artifact: cypress-azure-devops screenshots"
inputs:
PathtoPublish: cypress/screenshots
ArtifactName: "CypressAzureDevopsTestRunScreenshots"
condition: failed()
- task: PublishTestResults#2
displayName: "Publish Test Results"
condition: succeededOrFailed()
inputs:
testResultsFormat: "JUnit"
testResultsFiles: "results/*.xml"
searchFolder: $(System.DefaultWorkingDirectory)
mergeTestResults: true
testRunTitle: 'Test Results'
continueOnError: true
Saludos desde Argentina 🇦🇷
I want to fail the build pipeline if a single test failed with azure pipelines.
Azure can successfully detect that my tests entered a failed state however it gives a success state to the entire build pipeline:
The question is how to make azure give a failed build state if the tests stage failed?
Here's my azure-pipelines.yml :
# Build ASP.NET Core project using Azure Pipelines
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core?view=vsts
pool:
vmImage: 'Ubuntu 16.04'
variables:
buildConfiguration: 'Release'
steps:
- script: |
dotnet build --configuration $(buildConfiguration)
dotnet test dotnetcore-tests --configuration $(buildConfiguration) --logger trx
dotnet publish --configuration $(buildConfiguration) --output $BUILD_ARTIFACTSTAGINGDIRECTORY
- task: PublishTestResults#2
inputs:
testRunner: VSTest
testResultsFiles: '**/*.trx'
- task: PublishBuildArtifacts#1
The original answer didn't work for me, but it looks like there was a lot of discussion on this, and there's now a failTaskOnFailedTests param for the task. That seems to work.
- task: PublishTestResults#2
inputs:
testRunner: VSTest
testResultsFiles: '**/*.trx'
failTaskOnFailedTests: true
I'm still surprised this wasn't default behavior.
Try to add failOnStandardError: 'true' in the task inputs:
- task: PublishTestResults#2
inputs:
testRunner: VSTest
testResultsFiles: '**/*.trx'
failOnStandardError: 'true'
Untick the below-highlighted option