I'm completely new to Azure DevOps Pipelines so if I'm doing something incorrectly I'd appreciate a nod in the right direction... I setup a build pipeline and that seems to be working, now I'm trying to setup a release pipeline in order to run tests, it's mostly based on Microsoft's documentation:
https://learn.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=azure-devops
Before running tests I need to transform a config file to replace some variables like access keys, usernames, etc. What I setup is what I have below but for the life of me I can't figure out what text box Package or folder refers to. The documentation is super helpful as you can imagine:
File path to the package or a folder
but what package or what folder is this referring to??? I've tried several different things but everything errors with
##[error]Error: Nopackagefoundwithspecifiedpattern D:\a\r1\a\**\*.zip
or pretty much whatever I specify for a value.
The File Transform task supports the .zip files.
Test with the default File Transform task settings, I could reproduce this issue.
In Release pipeline, the file path could has one more node for the build artifacts .zip file.
The format example:
$(System.DefaultWorkingDirectory)\{Source alias name}\{Artifacts name}\*.zip
So you could try to set the $(System.DefaultWorkingDirectory)/**/**/*.zip in Package Or folder field
For example:
On the other hand, you can check the specific path in the Release log -> Download Artifacts Step.
$(System.DefaultWorkingDirectory): D:\a\r1\a
You could aslo use this specific path in the task.
Update:
If your file is Project Folder, you refer to the following sample:
File structure：
Task Settings:
Note:You only need to assign to the folder node.
You could also select the folder path via ... option.
Related
This is a TFVC repo in Azure, not Git. It is running in Azure DevOps Services, not local in Azure DevOps Server (2019). This is a classic pipeline, not YAML.
I got as far as adding a variable that contains the Label value I am looking to package into the zip file.
I can't figure out how to get the sources by Label value. In the Pipeline Get Sources step, I've narrowed the path down, but then I need to recursively get source files that have the Label in the variable I defined.
The next step is to zip those source files up, I've added an Archive task to which I will change the root folder from "build binaries" to the sources folder.
This is necessary for this particular project because we must pass the source files to the vendor as a zip for them to compile and install for us. The developers create/update the source files, build and test them locally, then apply a Label to the sources for a given push to the vendor.
When configuring 'Get sources' step, there is no any option or method that can only map the source files with the specified label.
As a workaround, in the pipeline job, you can try to add the steps to filter out the source files with the specified label, and use the Copy Files task to copy these files to a folder, then use the Archive Files task in this folder.
[UPDATE]
Normally, a pipeline run will automatically check out the file version (changeset) that triggers the run. If manually trigger the the pipeline, by default the run will check out the latest changeset if you do not specify one.
The labels are used to mark a version of a files or folders, so you also can get the specific version of files or folders via the labels.
In your case, you can try using the 'tf get' command to download the files with the specified labels.
I have created a sample Website project with a single page having HellowWord.aspx and HellowWord.aspx.cs. I am trying to create an Azure DevOps build pipeline for this project. The following are the tasks I have added to my build package.
But the publish artifacts always contains the aspx and aspx.cs file. Not sure which tasks I am supposed to add to make the proper publish package. Which will create proper dlls for .aspx file instead of aspx.cs.
Publish build artifacts task has an argument Path to publish, which defines the folder or file path to publish. This can be a fully-qualified path or a path relative to the root of the repository. Wildcards are not supported. Variables are supported. Example: $(Build.ArtifactStagingDirectory). By default, this argument uses variable $(Build.ArtifactStagingDirectory).
So you need to check your Copy files task, to see what you have copied to $(Build.ArtifactStagingDirectory), and copy the correct files in this task.
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/copy-files?view=azure-devops&tabs=yaml
I have a Release Pipeline setup to extract my build artifact and then I use the RegEx Find & Replace task to update a few configuration files on my static website before uploading via AzureBlob File Copy task.
What I have currently works. However I have to use the full source path to the "wwwroot" folder in order to for the correct files to be uploaded.
My concern is that my builds may change the directory structure that gets dropped as a build artifact which will break my release tasks.
I've tried to use various wildcards for the source path such as:
**/wwwroot/*
*/*wwwroot/*
And many other variations to no avail.
I read in some of the docs that wildcards won't work for directory paths in this task but was hoping there was a way to work around this as I have long term concerns about the path changing over time. I looked at a few other tasks in the marketplace but nothing seems to fit the bill and I couldn't find any definitive guidance on the matter. Any suggestions?
1.You can use $(System.DefaultWorkingDirectory)/**/wwwroot/*.*(or .json,.xml...) in Source input.
(If the wwwroot folder doesn't have subfolders and all files within that folder can match format *.*)
2.Otherwise I suggest you archive the wwwroot folder first before uploading it:
Use $(System.DefaultWorkingDirectory) to get working directory and then use full path(not recommend using * here) to archive the specific wwwroot folder. Then upload the zipped folder which contains all content of your wwwroot folder.
Azure DevOps Build artifact drop contains following files:
Project1.zip
Project1.deploy.cmd
Project2.zip
Project2.deploy.cmd
These files are a result of build output of a single solution.
I want to deploy Project1 web app to Azure.
I set up a release definition and add a Deploy Azure Web Service task to it. The task's path to package file or folder contains value which matches exactly one file Project1.zip . Nowhere do I specify any *.deploy.cmd files.
When the release executes it fails on that task with error:
More than one package matched with specified pattern: *.deploy.cmd. Please restrain the search pattern.
The only work-around I've found is to delete 2.deploy.cmd so that the deploy dask won't find multiple files using specified search pattern. But I would like to not delete it, especially because I would like to eventually deploy Project2 too. How to solve this problem?
I would suggest that you locate your artifacts in different folders.
You can use a Powershell task before you invoke your web deploy task to
create two folders
move the .cmd and .zip folders for project 1 into one folder
move the .cmd and .zip folders for project 2 into the second folder
You can then invoke your web deploy task against the folder path for project 1 and this should side-step your issue.
You can also extract the zip file and then point the web deploy task at the folder instead which may also help you if the above is either too complex or fails for your specific use case.
Don't use a wildcard. Specify an exact path to the file you want to deploy. If you want to deploy multiple things, use multiple tasks.
Im setting up a new build and deploy pipeline in Azure Devops. It is an older Web application with some transformation files for the web.config. In the old days we would build the same code x times depending on how many environments. This this is no longer necesary as I read from here https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/transforms-variable-substitution?view=vsts#xmltransform
it looks like the deploy pipeline can pick up the changes from my transform file.
But the problem is that my other transform files does not get included in the package so I get these warning message:
[warning]Unable to apply transformation for the given package. Verify the following.
[warning]1. Whether the Transformation is already applied for the MSBuild generated package during build. If yes, remove the <DependentUpon> tag for each config in the csproj file and rebuild.
[warning]2. Ensure that the config file and transformation files are present in the same folder inside the package.
And yes when i download the artifact the Web.[stage].config files are not there as suggested.
Is there some setting somewhere that let me include these files? Or stop them from being transformed?
For Web applications
MSBuild knows how to transform the web.config files based on the following settings/properties/parameters (in order)
Build Configuration dotnet publish --configuration Release
Publish profile dotnet publish --configuration Release /p:PublishProfile=FolderProfile
Environment dotnet publish --configuration Release /p:EnvironmentName=Production
Custom file transform dotnet publish --configuration Release /p:CustomTransformFileName=custom.transform
I think it's typical for developers to make this happen based on build configuration only, and I believe MSBuild (and dotnet) know how to do this based on the <DependentUpon>Web.config</DependentUpon> element in the Web.[configuration].config item in the project or build script file.
Azure DevOps Release Pipelines is a little different.
The pipeline wants to transform your web.config after the project has been built/published and doesn't know how to do that if MSBuild (or dotnet) has already made an attempt at it. Thus:
[warning]Unable to apply transformation for the given package. Verify the following.
[warning]1. Whether the Transformation is already applied for the MSBuild generated package during build. If yes, remove the tag for each config in the csproj file and rebuild.
[warning]2. Ensure that the config file and transformation files are present in the same folder inside the package.
The warning text states:
Remove the <DependentUpon> tag for each config in the csproj
Thus: you need to remove the tag from the csproj to prevent MSBuild from transforming the files
Or: you need to use the /p:TransformWebConfigEnabled=False argument to MSBuild. (note: I believe it is correct that this can be used w/o removing the dependent upon tag, but I could be wrong)
Make sure the transform source and target files are in the same folder inside the package.
There may be several ways to do this. I've chosen to mark the transform source config files as content to force MSBuild to include them in the published package.
Now you need to organize your release pipeline in accordance with the File Transforms and Value Substitutions documentation.
[section]Starting: IIS Web App Deploy
====================================
Task : IIS Web App Deploy
Description : Deploy a website or web application using Web Deploy
Version : 0.0.51
Author : Microsoft Corporation
Help : More information
====================================
...[command]C:...\ctt\ctt.exe s:C:...\Web.config t:C:...\Web.Release.config d:C:...\Web.config pw i
[command]C:...\ctt\ctt.exe s:C:...\Web.config t:C:...\Web.Development.config d:C:...\Web.config pw i
XML Transformations applied successfully
...
For Non-Web Applications Needing .config Transformation
Getting your .config files to the release pipeline can happen several ways. Here are two.
Your release should have "access" to the repository as a part of the artifact, which will ensure that the deploy agent downloads the source (not desirable IMHO).
You will need to include the web.[stage].config files as part of your build artifact with a copy task, or a minimatch that picks them up.
Once you have the .config files available to the release pipeline
You can use the File Transform Task or XDT Transform Task to perform the transformation operations.
Option 2 is the route I've gone.
Here is an image of what that task looks like for me.
That task puts the config in the artifact from the build that I can then use in the release pipeline without rebuilding xx times.
Cleanup
If you're in a position where you care to not have the transform files persisting on the agent after the release is complete, then you'll need to add that to your pipeline.