.NET Core WebJob Console App CI/CD using Azure DevOps Pipelines - azure-devops

I'm trying to build my console application through Azure DevOps. So to this I'm following this tutorial.
The follow images, are from what I already did.
Build Solution Pipeline
Build Solution Pipeline / Publish
Build Solution Pipeline / Artifact
Deploy WebJob Pipeline
Deploy WebJob Pipeline / Variables
When I run the Build Solution the zip seems to work, because I see it.
But when I run the Deploy WebJob Pipeline I get ##[error]D:\a\1\s\***.zip not found.. I tried wwwroot/App_Data/jobs/, but still the same error.
What could I be doing wrong? What's the right way to set the zippedArtifactPath?

You're following the tutorial incorrectly. The tutorial is telling you to create a release. You're using a build pipeline to try to release. Although you can do that, you shouldn't.
You have two options:
If you want to keep using the visual designer, use a release. Look at the "Release" tab for this. Releases can be tied to build artifacts and will handle downloading the build artifact automatically.
If you want to use YAML, refer to the YAML documentation and set up a multi-stage pipeline to release.

What could I be doing wrong?
Check your error messgae ##[error]D:\a\1\s\***.zip not found we can find in the second build pipeline, the PS tried to get the xx.zip in xxx\s folder while in first build pipeline you published the xx.zip to xxx\a folder.
The $(System.DefaultWorkingDirectory) for build pipeline is xx\s folder while that for release pipeline is xx\a folder. In first build pipeline we published the xx.zip to Build.ArtifactStagingDirectory which is a xx\a folder, so we can't access the xx.zip from xx\s folder in second build pipeline's PS script.
What's the right way to set the zippedArtifactPath?
It's not recommended to build and deploy one web app using two build pipelines. For normal logic, we should do this by using combination like build+release pipeline just like the Toturial and Daniel suggests above.

We can use this variable $(Release.PrimaryArtifactSourceAlias) to get the artifact directory.
In your powerShell script you can set path variable like:
$path = "$(System.DefaultWorkingDirectory)\$(Release.PrimaryArtifactSourceAlias)\webjobs_drop\[ZIP_File_Name].zip"

[your build artifact name]\webjobs_drop[your zipped files].zip
"your build artifact name" - you should get it from your release pipelines Artifacts stage from where you are selecting your build artifacts

Related

How to download multiple build artifacts in a Release pipeline on Azure Devops?

I am trying to create a Releasing stage that is meant to download 3 different build artifacts from 3 different pipelines in a project and deploy them on a target machine. When I create a release and deploy it on the target machine, the very first download build artifact task works fine but none of the following ones and I see the following error
"Artifact [buildnumber] not found for build [buildId]. Please ensure you have published artifacts in any previous phases of the current build."
Has anyone else seen this error or know why I am getting this error?
Thank
If you want to use Download Build Artifacts task to download different build artifacts from different pipelines, please select the “Specific build” option to find that particular artifact, as below.
If you use the default value: Current build, of course this task cannot find other build artifacts from other build pipelines. And then you will encounter this issue.
In addition, the new release will automatically download artifacts in below pre-defined “Download Artifacts” step.
Therefore, you could just add these 3 artifacts in release pipeline, and then you don’t need to use additional Download Build Artifacts task to download these artifacts. See: Release artifacts and artifact sources for details.

The $(Build.ArtifactStagingDirectory) variable's value changes when deploying a build in Azure DevOps Pipelines

I have a DACPAC deployment task which is failing, because for some reason the value of the $(Build.ArtifactStagingDirectory) pipeline variable is changing between the build pipeline and the release pipeline. In the build pipeline, the variable is set to C:\agent\_work\2\a, but in the release pipeline it's C:\agent\_work\r2\a. This is causing the release pipeline to fail when it tries to deploy the DACPAC artifact, because the folder it's looking in is empty; the folder where the artifact actually is is ignored. How do I make these variables consistent between the build and release pipelines so that the artifact is retrieved from the same folder it's generated in? These variables appear to be built in, so I don't see any way to change them. I could always hardcode a path, but that seems a bit kludgy...
In releases you have System.ArtifactsDirectory which is
The directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. Same as Agent.ReleaseDirectory and System.DefaultWorkingDirectory.
Example: C:\agent_work\r1\a
and in pipelines/builds Build.ArtifactStagingDirectory
The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: c:\agent_work\1\a
A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks.
Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself.
See Artifacts in Azure Pipelines.
This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
This is in line with your experience. And you cannot change it, as they are predefined. But can you clarify why this is a problem for you?
In the release pipeline, you can't directly access the files in the build pipeline, not only because the working directory is different, but also because they do not use the same agent. You need to download the artifacts first, and then use them in the release pipeline.
You can use the following ways to download artifacts:
Use the Download Build Artifacts task.
Go to the edit release pipeline page -> Select Add artifact -> Select Build -> Fill in the information related to the build pipeline (Notice the value of Source alias)-> Add it. You will find your artifacts are downloaded in $(System.ArtifactsDirectory)/${Source alias}
For more information about consuming artifacts in release pipelines, you can click this document.
Oh, I think I figured it out. Each release pipeline stage has an option called "Artifact download" which lets you specify which artifacts out of all those linked in the pipeline are actually used by that stage. I needed to check the appropriate checkboxes there in order to use the artifacts in the stage's tasks.

Does TFS has releases tab like we have at GitHub Releases

I am looking for hosting .exe files in Azure Devops. It seems to don't have feature similar to how we host executable or build files in GitHub for other people to download. Do we have such kind of feature to host the executables and have the latest commit tagged?
You can try publishing the executable or build files as Build Artifacts in Azure devops build pipeline.
You can create a pipeline in azure devops and using Publish build artifacts task to store the executable or build files in azure pipeline
See example here to create a classic azure pipeline. See Here for yaml pipeline example.
When you run the pipeline. You will see the commit hash and the files uploaded in the highlighted field of the build summary page shown in below screenshot. And you download the files from there.
You can retain this artifacts by Clicking retain in the pipeline run. See below
You can also change the retention policy for your pipeline. See here for more information.
Go the Project settings page-->Settings under Pipeline. See below:

Is there a way in an ADO Build Pipeline to only build one of the artifacts?

I have an ADO build pipeline that builds three artifacts. However, while I am developing, I only want one of the artifacts to be built since that is the artifact on which I am working and it takes longer for all of them to build and I don't want to wait. Can I disable the other artifacts from building?
As I know, you could not use UI to disable some of artifacts which build from one build pipeline. Because we does not provide this feature in VSTS now.
But as workaround, you can use Copy File task in your release to achieve this.
Specify the artifact what you want to work with in release pipeline, and copy it from File A(the source file where these build artifacts is) to File B(any file you want). And then, you can do other thing with this specific build.
Hope this could help -)

Automated build pipeline Salesforce Azure DevOps

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.