To achieve continuous deployment, we used a (classic) release pipeline on Azure DevOps to deploy a webservice to a VM in our intranet. To benefit of a yaml deployment pipeline, I replaced our former deployment pool agent on that VM with an environment agent.
For the actual deployment, we use the IIS Web App Deploy task. The source directory for this tasks defaults to $(System.DefaultWorkingDirectory)\**\*.zip. The $(System.DefaultWorkingDirectory) translates to the a subdirectory of the concrete release.
Unfortunately for me, the environment agent downloads the artifact next to the a-folder instead of into it like the environment pool agent. Thus the default settings of the deploy task cannot find it. I am aware that I can easily work around this issue by using $(System.DefaultWorkingDirectory)\..\**\*.zip. I was just wondering why Microsoft introduced such a development speed bump into the environment agents.
Is there any way I can make the environment agent download the artifact into $(System.DefaultWorkingDirectory) aka. a instead of next to it?
If you are using deployment job in yaml pipeline. The artifacts will be automatically downloaded to $(Pipeline.Workspace)/(folder next to $(System.DefaultWorkingDirectory)) in deployment jobs. See below extract from here:
Artifacts from the current pipeline are downloaded to $(Pipeline.Workspace)/.
Artifacts from the associated pipeline resource are downloaded to $(Pipeline.Workspace)/{pipeline resource identifier}/.
All available artifacts from the current pipeline and from the associated pipeline resources are automatically downloaded in deployment jobs and made available for your deployment. To prevent downloads, specify download: none.
To make the environment agent download the artifact into $(System.DefaultWorkingDirectory).
You can specify download: none. And use Download Pipeline Artifacts task and specify the path parameter to download your artifacts to $(System.DefaultWorkingDirectory). See below:
- deployment:
environment: Dev
strategy:
runOnce:
deploy:
steps:
- download: none #prevent automatically download
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'current'
targetPath: '$(System.DefaultWorkingDirectory)' # download to default folder.
Anther workaround is to change the source directory for IIS Web App Deploy task defaults to $(Pipeline.Workspace)\**\*.zip
When changing from Classic to YAML pipelines for deployments, you will probably need to change $(System.DefaultWorkingDirectory) to $(Pipeline.Workspace). You can verify this with the steps:
- pwsh: Get-ChildItem $(System.DefaultWorkingDirectory) -Recurse
displayName: Check System.DefaultWorkingDirectory
- pwsh: Get-ChildItem $(Pipeline.Workspace) -Recurse
displayName: Check Pipeline.Workspace
(Yes, this is an awfully verbose way of doing it. It will, though, give you more complete insight into the file structure supporting your job.)
Related
Having the same issue on a self hosted agent but I'm not specifying password in the yml. just specifying the vstsFeed
- checkout: self
submodules: true
persistCredentials: true
- task: NuGetToolInstaller#1
inputs:
versionSpec: 6.2.1
- task: UseDotNet#2
displayName: Using Dotnet Version 6.0.400
inputs:
packageType: 'sdk'
version: '6.0.400'
- task: DotNetCoreCLI#2
displayName: Restore Nuget packages
inputs:
command: 'restore'
projects: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'ba05a72a-c4fd-43a8-9505-a97db9bf4d00/6db9ddb0-5c18-4a24-a985-75924292d079'
and it fails with following error error NU1301: Unable to load the service index for source
Nuget feed is on another project of the same organization. I can see that pipeline produces a temp nuget config where it specifies username and password for this feed during run. Been breaking my head for the last 72 hours non-stop to find what is the issue. Azure pipelines and nuget sucks. 99% of the problems we had so far was with nuget not working smoothly with azure pipelines. Microsoft has to take a step back and resolve pipelines and nuget ssues.
Just to make sure: The NuGet feed is on the same Azure instance as the agent is registered with, right?
I remember similar issues on my on-premise Azure DevOps server, but also sometimes on the paid cloud variant. Sometimes it was flaky service state, sometimes the agent itself..
Kevin did give a good point with the permissions - if those are set, you're good to go from a permissions point of view - actually reader permission is enough for a restore - make sure to check the views panel too.
If after permissions check you still got issues, you might try my "just-making-sure-lines for your .yml file:
# NuGet Authentication (safety step, normally not required as all within the same organization/project)
- task: NuGetAuthenticate#1
displayName: "Nuget Authentication"
It shouldn't be required but I have it on all my pipes since I had such issues, and it reduced the occurence of the error line you posted in my cases (Hybrid devops architecture).
Another thing I ended up with is to specifiy the feeds explicitly in a repository-wide "NuGet.Config" file - and using this file within my yml files or with script lines instead of tasks now.
If nothing helps, enable diagnostics/verbose logging to get more error details. In the worst case: Log in to your agent machine, open a terminal in the same agent work folder and manually issue a dotnet restore command to see whats going on.
Post the additional results if still no progress.
Good luck
From your description, you are using the Nuget feed on another project of the same organization.
You need to check the following points:
Check the permission of the Build Service account.
Here are the steps:
Step1: Navigate to Artifacts ->Target Feed ->Feed Settings -> Permission.
Step2: Grant the Build service account Contributor Role . Build service account name: ProjectnamethePipelinelocated Build Service (Organization name)
For example:
Check the Limit job authorization scope to current project for non-release pipelines option is Enabled in Project Settings -> Settings.
If yes, you need to disable the option and then the pipeline can use the resource outside the project.
Note: To disable this option, you need to disable the option in Organization Settings-> Settings first. Then you could disable the option in Project level.
I have an Azure DevOps Build pipeline that publishes the entire repository as an artifact to be used with the Release pipeline.
# Publish artifacts to be used in release
- task: PublishBuildArtifacts#1
displayName: 'publish artifacts'
inputs:
PathtoPublish: '$(System.DefaultWorkingDirectory)'
ArtifactName: 'TerraformModule'
publishLocation: 'Container'
The build pipeline triggers the creation of a release pipeline where I try to deploy the terraform configuration.
I can successfully run terraform init in this pipeline but when I try to run plan or apply, I get the following error:
Looking at the screenshot, it looks like it tries to execute the command from /usr/local/bin instead of what I specified in the step? Confused by this. Below is the yaml for my plan step:
steps:
- task: ms-devlabs.custom-terraform-tasks.custom-terraform-release-task.TerraformTaskV3#3
displayName: 'terraform plan'
inputs:
provider: aws
command: plan
workingDirectory: '/home/vsts/work/r1/a/_terraform/TerraformModule/Projects/Potentium/Prod'
environmentServiceNameAWS: 'AWS-Terraform-Build'
I manually changed workingDirectory to where the Artifacts from the build pipeline were downloaded to. See log below for example:
2022-08-14T23:41:31.3359557Z Downloaded TerraformModule/Projects/Potentium/Prod/main.tf to /home/vsts/work/r1/a/_terraform/TerraformModule/Projects/Potentium/Prod/main.tf
The plan step in my build pipeline executes without any issues so I have a feeling it is something to do with the artefacts/extraction that is occurring in the download step. Looking for any advice.
I've had similar issues with the extraction phase, when using ExtractFiles#1 doing a similar thing with terraform. I think there's a bug in it, I could not get it to extract files back to the root of System.DefaultWorkingDirectory unless the root folder was included in the archiv, I am using ArchiveFiles#2. So I was ending up with /opt/az_devops/_work/*/s/s
My solution, was to shell out a command to do the extraction. No problems extracting to the root of System.DefaultWorkingDirectory
Just remember if you're running a subsequent terraform plan, by default the working directory System.DefaultWorkingDirectory will change between runs. So ensure you use these variables rather than an explicit reference.
I have separate yaml pipelines for CI and CD in Azure DevOps Services.
CI pipeline will publish an artifact to a file share location. \fileshare\project
And in the CD pipeline I am using the CI pipeline as resource so that I can deploy the artifact produced from the CI pipeline.
resources:
pipelines:
- pipeline: POC_pipeline # identifier for the pipeline resource
source: CI-pipeline_YAML # source pipeline definition name
My question is how can I download this artifact and what's the pre-defined variable name to get the path of the published artifact from CI-pipeline.
I tried using but it doesn't download anything, this only works when I push the artifact to Azure DevOps.
steps:
- download: POC_pipeline
It seems download task cannot download artifacts that published to a file share. I can reproduce the same issue. You can report this problem(Click Report a problem and choose Azure devops) to Microsoft development team.
As workaround, you can use Download Fileshare Artifacts task to download fileshare artifacts.
- task: DownloadFileshareArtifacts#1
inputs:
filesharePath: '\fileshare\project'
artifactName: artifactName
downloadPath: $(Build.ArtifactStagingDirectory)
The artifacts will be downloaded to folder specified in downloadPath. In above example you will find the artifacts in $(Build.ArtifactStagingDirectory)/artifactName (ie. C:\agent\_work\2\a\artifactName)
Check here to find more predefined variables.
You can also use Download Pipeline Artifacts task to download the fileshare artifacts. You need to specify the source as specific, and other project, pipeline,runVersion attributes. See below:
- task: DownloadPipelineArtifact#2
inputs:
source: specific
project: yourProjectName
pipeline: CI-pipeline_YAML
runVersion: latest
path: $(Build.ArtifactStagingDirectory)
The artifacts will be downloaded to folder specified in path.
Noted: you need to run your pipeline on self-hosted agents which can access the file share.(It will fail with error `Unable to read directory \fileshare\project" on cloud agents).
What is the correct way to run automated UI tests by a self-hosted agent?
I tried to add a tests step in the release pipeline but it's not working because the agent cannot find the DLLs with tests (they are in a few separate projects)
##[warning]No test assemblies found matching the pattern: **\Test.UI.dll,!**\*TestAdapter.dll,!**\obj\**.
Currently, the release pipeline is simple: one artifact from the build pipeline and one stage with the following steps:
1. IIS Web App Deploy
2. IIS Web App Manage
3. VsTest: tests are selected using Test assemblies option
No test assemblies found matching the pattern.
It seems that the .dll files don't exist in the artifact or under the path of the release agent. You may need to share more information about the Pipeline. (e.g. build agent, pipeline definition and vstest task definition)
Before this, you can refer to the following steps for troubleshooting.
First of all, you need to make sure that the .dll files exist in the build artifacts.
You could check this in Build Summary -> Artifacts. You could download it and check the files in the artifact.
If the files don't exist, you could add a Copy files task before the Publish Artifacts task.
For example:
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(agent.builddirectory)'
TargetFolder: '$(build.artifactstagingdirectory)'
enabled: false
Then the "VsTest" task will find the files in $(System.DefaultWorkingDirectory) by default(No customization). In release pipeline, the path is equals to C:\agent\_work\rx\a (e.g. C:\agent\_work\r1\a)
Since you are using the self-hosted agent , you could directly check the files in the target path on your local machine.
If you couldn't find the target files, you may need to modify the search folder or Test files path.
You also could check the file path in the Release Pipeline log -> Download Artifacts Step.
This is an ASP.NET Core 3.0 project that builds with no errors, but when it triggers the pipeline to release to Azure App Service, it fails with the following error:
2019-11-10T23:09:23.8008460Z ##[error]Error: No package found with specified pattern: D:\a\r1\a***.zip
What needs to be done to fix the release pipeline? The pipeline release is pulling the latest build as its artifact.
Assumptions
The following info assumes that you are appropriately publishing your build artifact from your Build pipeline, and that you have added the correct build artifact into you release pipeline.
In your release pipeline you have specified a build artifact in the Artifacts area
When adding your build artifact to your release pipeline, you chose to give it an alias of Build Artifact. This means that at the very lease (with default settings) your .zip file will be in some sub-directory of $(system.DefaultWorkingDirectory)/Build Artifact/
A new unique folder in the agent is created for every release pipeline when you initiate a release, and the artifacts are downloaded into that folder. The $(System.DefaultWorkingDirectory) variable maps to this folder.
To ensure the uniqueness of every artifact download, each artifact source linked to a release pipeline is automatically provided with a specific download location known as the source alias. This location can be accessed through the variable:
$(System.DefaultWorkingDirectory)\[source alias]
This uniqueness also ensures that, if you later rename a linked artifact source in its original location (for example, rename a build pipeline in Azure Pipelines or a project in Jenkins), you don't need to edit the task properties because the download location defined in the agent does not change.
The source alias is, by default, the name of the source selected when you linked the artifact source, prefixed with an underscore; depending on the type of the artifact source this will be the name of the build pipeline, job, project, or repository. You can edit the source alias from the artifacts tab of a release pipeline; for example, when you change the name of the build pipeline and you want to use a source alias that reflects the name of the build pipeline.
(from some of the abundant documentation
Instead of searching for your package using ***.zip (which isn't proper wildcard syntax) use Build Artifact/**/*.zip
** is for recursively searching into directories
(I don't know what folder)
* is for searching a part of a given level of the path
any file/folder that
starts with (SomeFile.*)
ends with (*File.zip)
and i think contains (*meFi*)
The pipeline YAML was missing the following tasks. Not sure why this isn't included in the ASP.NET Core template, very confusing for developers new to Azure DevOps.
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: true
- task: CopyFiles#2
inputs:
targetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
When adding an Artifact of Source type "Build", select "Default version" as "Latest from the build pipeline default branch with tags", as follows: