So I'm currently trying to proceed through the release pipeline portion of an Azure DevOps Fundamentals for beginners course on Udemy, and the goal is to deploy the code for a small webapp game called "Flatris" for the purpose of showing how Azure works.
I've been following along with all the steps as per the course, but when I run the release pipeline build, it consistently fails with the message:
"Error: No package found with specified pattern: D:\a\r1\a***.zipCheck if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
So far, I've double checked the function of the Web App resource provided through Azure, it's showing traffic when I try and run the pipelines, so it's not the problem(i think), I've double checked the repositories, and they seem to be functioning well(i think), I'm unsure about the artifacts and whether that may be the source of the problem, but theres not enough specificity in the error logs for me to accurately isolate where the problem is.
I don't know if anyone else has managed to get pat this problem, or if it's unique to me with something I'm doing, but any help would be greatly appreciated.
Error: No package found with specified pattern: D:\a\r1\a***.zip
Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
When we use release pipeline for our application, we have to specify the artifacts that make up the application. And the artifact is a deployable component of your application. It is typically produced through a Continuous Integration or a build pipeline. Azure Pipelines releases can deploy artifacts that are produced by a wide range of artifact sources such as Azure Pipelines build, Jenkins, or Team City.
According to the error message, it seems you are using the build pipeline as artifact resource in the release pipeline.
To resolve this issue, we need make sure we have use the Publish build artifacts task to publish the artifacts to the Azure Pipelines in the build pipeline.
Then select the above build pipeline when we select the artifact source type:
In this case, Azure release pipeline will download the artifact automatically when we execute the release pipeline, the artifact will be save in the default folder D:\a\r1\a. That will resolve your issue.
Related
I am working for a company that develops a lot of apps and we use Azure devops portal for all of our pipeline releases etc.
So, the general flow is that a developer will create a branch to do the development on and change the code on that branch. They would like to deploy that branch before it is merged back into the development line from a pipeline, rather than from visual studio, which they currently do. So, it's about giving the developer to the option to choose which branch to deploy from.
Has anyone done something similar or point me in the right direction to how I could go about this?
When creating the release, currently there is no build-in feature to choose which branch to deploy from, the release pipeline works with the corresponding source Artifacts configuration.
A good approach for your scenario is referring to the build id on your build pipeline (instead of release pipeline).
When running the build pipeline, you could choose the target branch and record the build id for this run.
In your release pipeline, you could check whether the source Artifacts is from your target branch by checking the build id.
I imported the SmartHotel360 project from azuredevopsdemogenerator.azurewebsites.net and would like to build and release the project however I have certain warnings. I successfully ran the build pipeline but when I want to release it I see this warning: The version provided for the build artifact source is invalid. I do not know from where to take this version. There is no option in the dropdown.
Using the Azure DevOps Services Demo Generator, we can create same SmartHotel360 project as below.
And it will automatically create a build pipeline and release pipeline in SmartHotel360 project. By reviewing the generated release pipeline: SmartHotel360_Website-Deploy, we can see below default primary artifact: Build - _SmartHotel_Petchecker-Web.
Clicking this artifact we will be redirected to a build pipeline which doesn’t exist, so we need to manually delete this artifact and then re-add our own artifact, as below.
Therefore, after successfully running the build pipeline and publishing the artifacts, we can create a new release, as below.
For the source alias you just need to set the Build Name, also on the version it will be automatically picked if you already have a successful build
We are using Azure Devops with Octopus deploy.
I have integrated the release steps, and release creation as well as release to first environment (Development in my case) is happening without any issue.
Issue is with subsequent releases.
Release fails in Semantic Versioning check of release name.
'1.2.1023.0508-09' is not a valid version string
at Octopus.Client.Model.SemanticVersion.Parse(String value, Boolean
preserveMissingComponents)
In the first stage, I am creating Octopus release, and deploying to Development environment in the same task (using Create Octopus Release task in Azure devops)
create-release "--project=<projectName>" "--releaseNumber=1.2.1023.0508-09" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
This step is successful.
In the next stage, I have tried 2 variations,
Promote Release
promote-release "--project=projectName" "--server=serverName"
"--apiKey=***" "--from=Development" "--to=envName"
Deploy Release
deploy-release "--project=projectName" "--releaseNumber=latest"
"--server=serverName" "--apiKey=***" "--deployTo=envName"
Both of them giving same error, saying release name is not a valid version string.
My confusion is, if the name is incorrect, even the first deployment should fail.
If it's correct and allowed, then subsequent stage release should also succeed.
If any one has faced such a issue before, or can add in some pointers to resolve this issue, it will be very helpful.
This sounds like a bug but I'd need more time to reproduce and verify. Can you share what version of Octopus and the Octopus Extension you are using?
My best suggestion to get going with this is to base the release number off of your Azure DevOps build number and use that variable to control what version is getting deployed. Using the 'latest' version could backfire if you have other releases created in between your stages.
If you can set your Azure DevOps build number to be in the same format that you want your Octopus release number (1.2.1023.0508-09), you can use the following commands to build and promote a release.
create-release "--project=<projectName>" "--releaseNumber=$(Build.BuildNumber)" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
deploy-release "--project=projectName" "--releaseNumber=$(Build.BuildNumber)" "--server=serverName" "--apiKey=***" "--deployTo=envName"
This will make sure that you are promoting the same release that was created in the pipeline.
Just in case if someone came here looking for solution, below are the steps I took to solve the problem,
For first stage (dev in my case), create a new release. If you have multiple tenants, add them. Do not forget to add Package Version. This is especially needed when you have multiple versions of artifacts getting created. I faced hard time resolving this. if you do not add PackageVersion, latest available artifact is picked.
For further stages, DO NOT promote release. Instead, deploy release. This way, you can pass the same release number as configured in first stage. In my case, I kept the stage name same as my environment name. So I was able to use variable for env as well. I copied this stage for 4 different environments.
So I have a project set up as a polyrepo, meaning all services and libraries are in different repos.
Now, I've updated the service projects to reference the library project directly when using Debug as the build config in visual studio, and the package on NuGet when building in Release, on Azure DevOps.
The problem I am trying to solve is that my service builds sometimes fail when I've updated the library because the Library build hasn't completed and update NuGet yet.
What are my options here? Is there a way to ensure that the Library build completes first before the service builds start, or something similar?
Since you are using the Release feature in Azure Devops, I suggest that you could split the whole process into two stages (Library Build Stage and Service Build Stage).
For example:
These two stages are connected by After Stage relationship.
Then when the Library Stage completes , the Service Build stage will start.
If the two stages need to specify different files in the build, you could select the target files in the Visual Studio Build task -> Solution.
By the way, if Service Build stage needs to use the build results of Library Build stage, I suggest that you can use the same Self-hosted agents to run the release.
You can define it in Tasks -> Agent Job -> Demands.
Updates:
Since the Service Build and Library Build are two pipelines, you could try the following steps to order the Build running Step.
Step1: Set the CI trigger(continuous integration) in Library Build. This could make sure the commits could trigger the Library Build.
Step2: Disable the CI trigger in Service Build. Then Set the Pipeline trigger in Service Build. You could set the Library Build trigger the Service Build.
In this case, you could make sure that the Service Build will run after the Library Build.
A release can be triggered when the build artifact is available as shown in screenshot below.
So does this necessitate that for the release pipeline (configured for build artifact) to get triggered, the build pipeline must have the "publish artifact" task?
Agree with Shayki Abramczyk, the answer is No. But I think maybe you need more descriptions to help you understand ~
In your situation, you set build pipeline as release pipeline's artifact. If you've checked this document you would find these statements:
1.When authoring a release pipeline, you link the appropriate artifact sources to your release pipeline. For example, you might link an Azure Pipelines build pipeline or a Jenkins project to your release pipeline.
2.Note from here:
You must include a Publish Artifacts task in your build pipeline. For XAML build pipelines, an artifact with the name drop is published implicitly.
3.Auto-trigger releases feature(CD trigger in artifact): New releases can be created automatically when new builds (including XAML builds) are produced. See Continuous Deployment for details. You do not need to configure anything within the build pipeline. See the notes above for differences between version of TFS.
To sum up, the artifact source here represents a build pipeline instead of the outputs of a build pipeline. So when you enabled the CD trigger in artifact(in your situation a build pipeline), the release is triggered whenever a new build finishes. And this behavior won't be affected by whether the build pipeline has Publish Artifact task to publish the outputs from it.
For the 2.Note: It can be considered as we must include a Publish Artifacts task in build pipeline so that the release pipeline can access the outputs of build pipeline. And then we can deploy the outputs(.dll/.exe or what) to target machines/environments. (Actually we think the must in document should be replaced with It's recommended to/should)
Publish Artifacts task make the build+release process meaningful. Cause if our release pipeline can't access outputs of build pipeline, what should we use to deploy? But whether this task exists or not won't actually affect the CD trigger. (Just like the third statement:You do not need to configure anything within the build pipeline)
The answer is No, the release will be triggered when the build finished even he doesn't have Publish Artifacts step.