dotnet build failing because project not found - azure-devops

I have a YAML file with tasks to copy & publish files to artifact and download the artifact:
Log for task DownloadPipelineArtifact#2:
Downloading: D:\a\1\s\Service\ProjectName\Repositories.Logging/Repositories.Logging.csproj
Then, I have a task to build. The build fails on this task.
Log for task DotNetCoreCLI#2:
Skipping project "D:\a\1\s\Service\ProjectName\Repositories.Logging\Repositories.Logging.csproj" because it was not found.
Why does it say skipping project because it was not found even though log for DownloadPipelineArtifact#2 shows the same path? What am I missing and how do I fix that?
UPDATE:
I know that there is a difference in the slashes. However, I don't have conrol over updating the slashes:
Tasks to copy, publish, download:
- task: CopyFiles#2
displayName: 'copy service'
inputs:
SourceFolder: 'Service\ProjectName'
contents: '**'
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
displayName: 'publish artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Build.BuildNumber)'
- task: DownloadPipelineArtifact#2
inputs:
artifactName: '$(Build.BuildNumber)'
downloadPath: Service\ProjectName
On updating download task to:
- task: DownloadBuildArtifacts#0
inputs:
artifactName: '$(Build.BuildNumber)'
downloadPath: $(System.DefaultWorkingDirectory)\Service\ProjectName
I see the following log from DownloadBuildArtifacts#0:
Downloaded to D:\a\1\s\Service\ProjectName\20201118.10\Repositories.Logging\Repositories.Logging.csproj
and following log from DotNetCoreCLI#2:
D:\a\1\s\Service\ProjectName\Repositories.Logging\Repositories.Logging.csproj because it was not found
In this case I see the slashes correctly. Is it possible to remove:
20201118.10
from downloadPath so that it becomes:
D:\a\1\s\Service\ProjectName\Repositories.Logging\Repositories.Logging.csproj

Is it possible to remove 20201118.10 from downloadPath.
We could not remove the artifact Name 20201118.10 when we use the task Download build artifacts.
When we check the task Download build artifacts in the classic mode, we could to know the option Artifact name is required:
To resolve this issue, we could add a copy task to copy files to $(System.DefaultWorkingDirectory)\Service\ProjectName folder
- task: CopyFiles#2
displayName: 'Move artifact Name'
inputs:
SourceFolder: '$(System.DefaultWorkingDirectory)\Service\ProjectName\$(Build.BuildNumber)'
TargetFolder: '$(System.DefaultWorkingDirectory)\Service\ProjectName'
Or you could specify the path including the artifact Name 20201118.10 when you build the project:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
projects: '$(System.DefaultWorkingDirectory)\Service\ProjectName\$(Build.BuildNumber)\Repositories.Logging\Repositories.Logging.csproj'

Related

How to store build artifacts in Artifacts feed?

I have a build pipeline that publishes a release artifact for consumption by the release pipeline.
pool:
name: Azure Pipelines
demands:
- npm
- msbuild
steps:
- task: Cache#2
displayName: 'npm Cache'
inputs:
key: 'npm | "$(Agent.OS)" | $(System.DefaultWorkingDirectory)/ABCDashboard/Angular/package-lock.json'
path: '$(System.DefaultWorkingDirectory)/ABCDashboard/Angular/node_modules'
cacheHitVar: 'CACHE_RESTORED'
restoreKeys: 'npm | "$(Agent.OS)"'
- task: Npm#1
displayName: 'npm ci'
inputs:
command: ci
workingDir: ABCDashboard/Angular
verbose: false
condition: eq(variables['CACHE_RESTORED'],False)
- task: Npm#1
displayName: 'npm custom: angular build'
inputs:
command: custom
workingDir: ABCDashboard/Angular
verbose: false
customCommand: 'run-script build -- --prod'
- task: NuGetCommand#2
displayName: 'NuGet restore'
- task: MSBuild#1
displayName: '.Net build | Build solution (No need to build test as well)'
inputs:
solution: 'ABCDashboard/*.csproj'
msbuildArchitecture: x64
configuration: Release
msbuildArguments: '/p:OutputPath=$(Build.ArtifactStagingDirectory)'
clean: true
- task: Snyk.snyk-security-scan.custom-build-release-task.SnykSecurityScan#0
displayName: 'Snyk scan for open source vulnerabilities'
inputs:
serviceConnectionEndpoint: SnykAuthFreeTier
failOnIssues: false
testDirectory: ABCDashboard
additionalArguments: '-d --all-projects'
- task: CopyFiles#2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)/_PublishedWebsites/ABCDashboard'
inputs:
SourceFolder: ABCDashboard
Contents: |
Bundles/**
!(packages.config|phantomjs-license.txt)
TargetFolder: '$(Build.ArtifactStagingDirectory)/_PublishedWebsites/ABCDashboard'
- script: |
cd $(Build.ArtifactStagingDirectory)/_PublishedWebsites/ABCDashboard
ls -ltr
displayName: 'List artifacts under $(Build.ArtifactStagingDirectory)/_PublishedWebsites/ABCDashboard'
enabled: false
- task: CopyFiles#2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)/Release'
inputs:
SourceFolder: '$(Build.ArtifactStagingDirectory)/_PublishedWebsites/ABCDashboard'
Contents: |
assets/**
bin/**
Bundles/**
Content/**
Scripts/**
Views/**
Web.config
Web.Dev.config
Web.Test.config
Web.Prod.config
Web.Beta.config
Web.Sandbox.config
ApplicationInsights.config
*.asax
*.ico
*.txt
TargetFolder: '$(Build.ArtifactStagingDirectory)/Release'
- task: ArchiveFiles#2
displayName: 'Archive $(Build.ArtifactStagingDirectory)/Release'
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/Release'
includeRootFolder: false
archiveFile: '$(Build.ArtifactStagingDirectory)/Release/$(Build.BuildId).zip'
verbose: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: Release'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)/Release'
ArtifactName: Release
I am looking into Azure Devops Artifacts, and from what I understand, we can create feeds to store those published build artifacts?
From my understanding, those kind of build artifacts my pipeline publishes are considered "Universal Packages"? and If so, I would have to add a Universal Package task like so in order for the build artifact (e.g. Release) to be stored in the Artifacts feed?
- task: UniversalPackages#0
displayName: 'Universal publish'
inputs:
command: publish
vstsFeedPublish: 'feedname'
vstsFeedPackagePublish: test
versionOption: custom
versionPublish: 1.1.0
I had already gone ahead and created a feed, do I just wait for next time I run a pipeline for a Release artifact to show up in the feed? or do I have to add "upstream sources" first? If upstream sources is a required step, I selected "Azure Artifacts feed in this organization" as the upstream source type and then when going over the configuration setting, for some reason, it's complaining that "This feed has no available views to be used as an upstream source" despite defined views as shown here:
Based on your requirement, you can use feed to store Build artifacts.
From my understanding, those kind of build artifacts my pipeline publishes are considered "Universal Packages"?
Your understanding is correct. You can use Universal Package Publish task to upload the build artifacts to Azure Feed.
Do i just wait for next time I run a pipeline for a Release artifact to show up in the feed? or do i have to add "upstream sources" first?
You don't need to add upstream sources for the feed.
To publish the Universal Package, you can directly use Universal Package Publish task in Pipeline.
For example:
- task: UniversalPackages#0
displayName: 'Universal publish'
inputs:
command: publish
vstsFeedPublish: 'name'
vstsFeedPackagePublish: kevintest
Result:
To use the published Universal Package, you can directly use Universal Package download task.
For example:
- task: UniversalPackages#0
displayName: 'Universal download'
inputs:
command: download
vstsFeed: 'name'
vstsFeedPackage: 'name'
vstsPackageVersion: 0.0.1

Why does Azure Devops change the date on dlls downloaded from Nuget?

I notice that files such as EntityFramework.Dll are deployed with the current time.
I have been experiencing this error and I resolved it by copying dlls from my development machine to the overwrite deployed dlls.
What causes the date to change on the dlls?
azure-pipelines.yml is
trigger:
- master
pool:
vmImage: 'VS2017-Win2016'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '**\*.sln'
feedsToUse: config
nugetConfigPath: 'MyService.ServiceHost/nuget.config'
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: CopyFiles#2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: |
$(Build.SourcesDirectory)\MyService.ServiceHost\bin\debug\**\*.*
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
inputs:
artifactName: 'drop'
my nuget.config references
and a private feed in https://pkgs.dev.azure.com
[Update]
I tried adding preserveTimestamp: True to the CopyFiles#2 task but it made no difference
- task: CopyFiles#2
displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: |
$(Build.SourcesDirectory)\MyService.ServiceHost\bin\debug\**\*.*
TargetFolder: '$(build.artifactstagingdirectory)'
preserveTimestamp: True
[Update]
Leo advises a work around.
However I am wondering how to unzip the file to release
Currently my release pipeline contains
copy C:\azagent\A2\_work\r1\a\_PreMyFolder\drop\MyService.ServiceHost\bin\Debug\*.* "C:\Program Files (x86)\MyCompany\MyService Service"
Why does Azure Devops change the date on dlls downloaded from Nuget?
That because the default value of the preserveTimestamp option is False in the Copy Files task.
- task: CopyFiles#2
inputs:
#sourceFolder: # Optional
#contents: '**'
targetFolder:
#preserveTimestamp: false # Optional
To resolve this issue, you just need change the value to True.
- task: CopyFiles#2
inputs:
sourceFolder:
contents: '**'
targetFolder:
preserveTimestamp: True
Update:
I tried adding preserveTimestamp: True to the CopyFiles#2 task but it
made no difference
When I first tested this issue, I found that the copy task would modify the Timestamp of the file. This is indeed the case. And found a solution using option preserveTimestamp. I thought this was the whole issue until Kirsten Greed replied to me that this solution did not work.
I had to test the issue again and found that the PublishBuildArtifacts task would also modify the Timestamp of the file, but there is no such preserveTimestamp option like copy task. We could found some similar thread here and here, but none of them gives a solution/workaround.
The workaround I currently think of is that you could try to Bundle the artifacts in a compressed zip file, then unzip it when you use it.
So, I use the Archive files instead of the copy task:
- task: ArchiveFiles#2
displayName: 'Archive $(Build.SourcesDirectory)\TestSample\TestSample\bin\Debug'
inputs:
rootFolderOrFile: '$(Build.SourcesDirectory)\TestSample\TestSample\bin\Debug'
archiveFile: '$(Build.ArtifactStagingDirectory)/Test.zip'
Then publish this zip file as artifact:
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
Now, I could keep the Timestamp for the files:
Hope this helps.
I have this same problem. If I zip the files or simply do a Machine File Copy task to the server the date modified is always updated by Azure Dev Ops.
I don't believe is it currently possible to deploy from Dev Ops whilst preserving the date modified of the files.

AzureDevOps Duplicate dist folder in pipelines build ? Why?

There is a duplication of a dist folder in the artifacts produced by the AzureDevOps -> Pipelines, the duplication is the /dist folder and also /drop/dist folder. EDIT: Full azure-pipeline.yml file
# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/javascript
# Major modification referencing
# https://dev.to/thisdotmedia/continuously-integrating-angular-with-azure-devops-2k9l
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
# Build angular app area
- script: npm install
displayName: 'npm install'
- script: npx ng build --prod
displayName: 'npm build'
# Testing area
- script: npm install puppeteer --save-dev
displayName: 'Installing puppeteer (Headless browser for testing)'
- script: npx ng test --watch=false --codeCoverage=true
displayName: 'Running Tests'
- task: PublishTestResults#2
condition: succeededOrFailed()
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/TEST-*.xml'
displayName: 'Publish Test Results'
# Publishing items
# deploy.psl (Powershell script to deploy)
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: 'deploy.ps1'
ArtifactName: 'drop'
publishLocation: 'Container'
# Firebase.json
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: Firebase.json'
inputs:
PathtoPublish: 'firebase.json'
ArtifactName: 'drop'
publishLocation: 'Container'
# App
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: 'dist'
ArtifactName: 'drop/dist'
publishLocation: 'Container'
displayName: 'Publish Artifacts'
# Code Coverage Results
- task: PublishCodeCoverageResults#1
condition: succeededOrFailed()
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: '$(Build.SourcesDirectory)/coverage/ng-azure-devops/cobertura-coverage.xml'
displayName: 'Publish Code Coverage Results'
- script: npx ng lint
displayName: 'Code Analysis'
I've tried the using 'drop' as the ArtifactName, which will NOT produce a duplicate folder artifact anywhere. I am very confused on why 'drop/dist' will produce another '/dist' artifact
AzureDevOps Duplicate dist folder in pipelines build ? Why?
I could reproduce this issue on my side.
When we use the publish the artifacts dist folder with ArtifactName: drop/dist, Azure Devops will create a new folder drop first, then publish the artifacts dist folder to that folder drop.
You can get this message from the build log:
Upload '/home/vsts/work/1/s/dist' to file container:
'#/3620698/drop/dist'
However, the drop folder is already present by default. When we publish the dist folder with with ArtifactName: drop/dist, there are two drop folder, then Azure devops will publish dist folder to those two drop folders:
In order to understand this problem more clearly, you could disable the Multi-stage pipelines in the Preview features, then you will get the output:
Obviously, there are two drop folders here, that is the reason why you get the Duplicate dist folder in pipelines build.
So, to resolve this issue, we could change the ArtifactName: drop/dist to ArtifactName: dropTest/dist:
Now, the duplicate dist folder disappears.
Hope this helps.

Can you copy files from one VSTS build agent to another?

Is it possible to copy files from one build agent to another and kick it off as a part of the pipeline task?
One build agent is Linux but I need to continue my work on Windows agent.
Following Hanna's solution, attached more detailed working solution:
Agent-1 and Agent-2 are two different machines from a different agent pool.
Agent-1 does 2 steps:
CopyFiles - writes the file 'livne.txt' (can be any pattern) from the default working directory into the artifact's staging directory
PublishPipelineArtifact - publishes an artifact called: 'PROJECT_NAME' contains all the files copied into the default working directory.
Agent-2 does one main task:
DownloadPipelineArtifact - downloads the file 'livne.txt' (can be any pattern) from the 'PROJECT_NAME' artifact into the current agent's working directory.
simple bash script to make sure 'livne.txt' indeed exists on the working directory.
pool:
name: Agent-1
- task: CopyFiles#2
displayName: 'Copy txt file'
inputs:
SourceFolder: '$(system.DefaultWorkingDirectory)'
Contents: livne.txt
TargetFolder: '$(build.ArtifactStagingDirectory)'
- task: PublishPipelineArtifact#1
displayName: 'Publish Pipeline Artifact'
inputs:
targetPath: '$(build.ArtifactStagingDirectory)'
artifact: 'PROJECT_NAME'
dependsOn: Job_1
pool:
name: Self Hosted Ubuntu for Docker Multiplatform
steps:
- task: DownloadPipelineArtifact#2
displayName: 'Download Pipeline Artifact'
inputs:
artifactName: 'PROJECT_NAME'
itemPattern: livne.txt
targetPath: '$(build.ArtifactStagingDirectory)'
- bash: |
ls $(build.ArtifactStagingDirectory)
cat $(build.ArtifactStagingDirectory)/livne.txt
displayName: 'Bash Script'
I think the best way to do this is typically to publish the files as artefacts of the pipeline and then download those artefacts again on the second agent. I have done this in projects before when one machine is consuming test results from the test agent to build reports.
You might imagine your pipeline would look something like this:
- job: Build
displayName: Build on Linux
steps:
...
- task: PublishPipelineArtifact#1
displayName: Publish Built binaries from Linux
inputs:
path: $(Build.SourcesDirectory)/bin/
artifact: Binaries
- job: Additional
displayName: Do something with the binaries on windows
steps:
- task: DownloadPipelineArtifact#2
inputs:
artifact: Binaries
targetPath: $(Pipeline.Workspace)/Binaries
...
I hope this helps! :)

Can I get a download link for my WPF application from Azure Devops

I'm developing a Windows WPF application that I have set up a build pipeline for in Azure Devops. My problem is that I can't seem to figure out any way to download the artifacts after successfully completing the build.
Is it possible to get a link to a zip containing all the built files somehow. How can I get my files? I don't want to publish to NPM or NuGet or anything like that, just download to my desktop for now.
Thanks!
Edit: This is my build configuration
trigger:
- master
pr:
- master
pool:
vmImage: 'VS2017-Win2016'
variables:
solution: '**/*.sln'
buildPlatform: 'x64'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#0
displayName: 'NuGet Tool Installer'
- task: NuGetCommand#2
displayName: 'Restore NuGet dependencies'
inputs:
restoreSolution: '$(solution)'
- task: VSBuild#1
displayName: 'Build $(buildConfiguration) $(buildPlatform)'
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: CopyFiles#2
displayName: 'Copy files'
inputs:
Contents: '_buildOutput\\**\\*.dll'
TargetFolder: $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts#1
displayName: 'Publishing artifact drop'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'drop'
publishLocation: 'filePath'
targetPath: '$(Build.ArtifactStagingDirectory)\\outdir\\$(Build.DefinitionName)\\$(Build.BuildNumber)'
- task: DownloadBuildArtifacts#0
inputs:
buildType: 'current'
downloadType: 'single'
artifactName: 'drop'
downloadPath: '$(System.ArtifactsDirectory)'
You may use 2 ways:
Copy the download link from the build results:
Use link from this example (Artifacts - Get Artifact).
You need to know the Id for your build.
Then you may use download link with this format (for drop by default):
https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName=drop&api-version=5.0&%24format=zip
Updates (if you use yaml):
You have to use the "Publish Artifact" task if you want to work with build result and have the "Artifact" button.
You can publish it to Azure DevOps (by default):
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: 'Your folder with build results'
Also you can publish you results to the some file share:
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: 'Your folder with build results'
publishLocation: FilePath
TargetPath: '\\my\share\$(Build.DefinitionName)\$(Build.BuildNumber)'
Updates 2:
If try to download your with format:
https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName=drop&api-version=5.0
You will get json with urls:
You may add "&%24format=zip" to the end of url and get a zip file:
Update 3
This is the part of my yaml build definition that was converted from standard build:
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(build.sourcesdirectory)'
Contents: '**\bin\$(buildConfiguration)\**'
TargetFolder: '$(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'