I cannot use the Publish Build Artifacts Task in a release-definition, I'm getting the following error:
ErrorHostTypeNotSupported: This task must run in a build to publish artifacts to Visual Studio Team Services/TFS.
So my question is:
How can I save a file from a release-definition?
Why I want to achieve this:
I'm using a Deploy to Kubernetes Task in my release definition (which deploys a microservice with a yaml file to azure aks), this yaml file is tokenized during the release (I'm replacing the build-id). So at the end, I want to be able to download this file for each release and to use it for a manual deployment (if necessary).
Thanks for your help.
There is no container for artifacts in Release Management, so you cannot use that task in Release.
As a workaround, you can use ##vso[task.uploadfile]local file path command in VSTS Task Logging Command to upload the file.
Upload user interested file as additional log information to the
current timeline record. The file shall be available for download
along with task logs.
To do this, add a powershell task in your release definition like below:
When you want to use the file, download the release logs as zip, the file will be included in it.
Related
I lost a file which is still available in the library inside the DevOps Library.
Is there a way to save a local copy somehow?
It's still possible to use in a pipeline, but I have no idea to get it to my local computer.
You can use the Download Secure File task to download the file in the pipeline and then use Publish Build Artifacts task to publish the file as build artifacts.
See below when downloading using Download Secure File:
Once downloaded, use the name value that is set on the task (or "Reference name" in the classic editor) to reference the path to the secure file on the agent machine. For example, if the task is given the name mySecureFile, its path can be referenced in the pipeline as $(mySecureFile.secureFilePath)
So in the Publish Build Artifacts task set the Path to publish to $(mySecureFile.secureFilePath)
Then you can download the file from the build summary page by clicking the related artifacts. See below:
Within Azure Devops I have a build pipeline which builds and publishes artifacts and a release pipeline which downloads those artifacts, defines some infrastructure configuration, and batch uploads the artifacts to a web container.
After the configuration definition I want to add a task to fetch the clientId of an AD registered app, dumps it into a json file and copies the file in the same folder as the build artifacts. The json has to be uploaded to the web container to provide runtime configuration for a spa app.
What I have tried:
generate a json in a release task and copy it into said folder
commit an empty json in the code, have it published as build artifact and update its content in a release task
use the file transform task which only seem to allow updating a key / value, not generating a new one
The contents of the folder which gets uploaded seem to be locked.
Is that correct ? What can I do to achieve my goal ?
Releases don't publish artifacts. Releases consume published artifacts. A release can be run multiple times for the same build. A release can have multiple environments. What you want to do would fall apart immediately in any of those scenarios.
What you should do is write a custom BASH or Powershell script (depending on your preferences and OS) that does exactly what you describe:
Generate an appropriate JSON file
Upload the JSON file to the "web container"
You haven't provided any details about what a "web container" is or what your deployment environment is (i.e. AWS, Azure, containers running in Kubernetes), so that's the most thorough answer that can be provided.
I am trying an automated build process in Azure DevOps for Salesforce. whenever a change is pushed to the repository, my build is triggered and it is working fine and pushing the changes to the related sandbox. Here is the proof for the same
Success Build Process.
The configuration of the build is Build configuration.
The build is working fine as expected. I now want to create a release which will push this change to a different environment, and I don't want this to be automated, hence the option of creating the release. The build path to the ant file in my release is exactly as it should be but I am getting this error. Release Error.
The release configuration is Release configuration
My Repository folder structure is: Folder structure. and my build.xml is within the deploy folder.
I don't know what I am doing wrong but the release is always failing and giving me the error which says:
Error: Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Based on the first image (Success Build Process), seems that you already have deployed your changes on that sandbox. Working with metadata deployment in Salesforce is different from java and .net, keep in mind that you already have the "executables", all those XML are already the code that you will change on the environment.
The second point is that on release you are in another agent, Buil and Release pipelines runs have their own lifecycle, so the code existing at the Build pipeline is not available until you send it on "drop" artifact, see Publish Build Artifacts task documentation. So that use copy task to put build.xml on publish folder, then you'll be able to use it on Release pipeline.
When you are executing ant go the /deploy folder and execute your command or check for your ant version using ant -version command.
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.
I'm trying to upload log files created by a 3rd party exe during a deployment and including it in the results of my deployment, on a separate tab if possible.
I tried using the publish artifact build tasks but that only works for build not release.
I tried logging tasks but ##vso[build.uploadlog]<local file path> seems to be for builds as well since it complains about finding a container for the build.
Release management does not have a container for build artifacts, that's why you see this error message.
You can try with following task:
Write-host "##vso[task.uploadfile]<filename>"
View and download attachments associated with releases
Would you like to upload additional logs or diagnostics or images when
running tasks in a release? This feature enables users to upload
additional files during deployments. To upload a new file, use the
following agent command in your script:
Write-host "##vso[task.uploadfile]"
The file is then available as part of the release logs. When you
download all the logs associated with the release, you will be able to
retrieve this file as well.
You can also add a powershell script task in your release definition to read the log files and output it to the console. Then you will be see the content of the log files from "Logs" tab powershell script step. And you can also click "Download all logs as zip" to download the logs.
I hope to provide more clarity to those looking for an answer. The accepted answer does work.
I had a lot of files (browser screenshots) to add to the release logs. Here's what I did:
If you have lots of files, Archive them into a zip.
Attach the zip to the log files via powershell.
Download the logs
Unzip and enjoy!
#DonRolling, thanks for the detailed answer. In my case instead of adding a new task to compress the folder i just included that part in the powershell:
Compress-Archive -Path "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -DestinationPath "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -Force
Write-host "##vso[task.uploadfile]$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots.zip"
I was facing a similar problem but I also wanted to use the Artifacts in a subsequent agent phase.
Based on the previous answers I created an Extension that offers the possibility to:
Upload a file or a folder to the Release Logs
Automatically download an Artifact from the logs that was previously uploaded
The upload task is making use of the logging command as it was mentioned before. The download task then queries the Azure DevOps REST Api to download all logs collected thus far, tries to find the specified artifact and copies it to a specific place.
If anyone is interested, it can be found on the Marketplace