For unknow reason, my pipeline fails when I try to push modification on acceptance. There is no modification in any .csproj files since the last successful push...
I think this is due to an upgrade to .net6 but I don't know how to solve it:
Last successful push:
failed push:
=> line 15: welcome to .NET 6.0
I try to force .net core sdk to 3.1, but it seems to do affect the continuous Web job.
I also try to do this:
Based on this topic: How do I fix Azure pipeline error NETSDK1152?
but it also failed.
I got clueless... If someone has any idea? Thank you :)
I try to force .net core sdk to 3.1, but it seems to do affect the continuous Web job.
I also try to do this:
Based on this topic: How do I fix Azure pipeline error NETSDK1152?
Related
I have been using Azure pipelines for many years. Recently I switched to using from azure Microsoft Hosted Agents to Self hosted Agent which are running in a VMSS.
Since switching, I have noticed MANY builds fail because of an error like below. This happens quite often and very randomly. The build will be successful if I rerun the build.
---> Running in 3619316996da
unexpected EOF
##[error]unexpected EOF
##[error]The process '/usr/bin/docker' failed with exit code 1
Finishing: Build an image
Has anyone had such an issue or can help enlighten me where to look. Its pretty frustrating especially since the issue seems to be random and didn't happen with Microsoft Hosted Agents.
Problem was solved after updating linux/Docker to the latest version
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'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.
I have create a function app using visual studio code and then published it. Function app works fine. I am now using code deployment feature(KUDU) in the function portal and its skipping the build. Below is the log
9:55:46 AM Updating submodules.
9:55:47 AM Preparing deployment for commit id '5642d3aeec'.
9:55:48 AM Skipping build. Project type: Run-From-Zip
9:55:48 AM Skipping post build. Project type: Run-From-Zip
9:55:48 AM Triggering recycle (preview mode disabled).
9:55:49 AM Syncing 4 function triggers with payload size 452 bytes successful.
9:55:50 AM Deployment successful.
Deployment is happening when ever the code is checked in to Github. But its not picking the latest code. I did set the app setting WEBSITE_RUN_FROM_PACKAGE to "1".
What changes do I need to make to pick the latest build.
Thanks in advance
I have had a similar scenario and a similar experience, but I did not manually set WEBSITE_RUN_FROM_PACKAGE, though I found it set to 1. I assume it was set by the VS Code deployment, which first created the Azure Functions App. Then when I switched to using Kudu Continuous Integration, the setting was still around. I deleted that setting from Configuration, and now the problem is fixed.
I've got an ASP.NET MVC web app with a set of Selenium UI integration tests for it. I want to put this in Azure, and apply continuous delivery like this:
I commit a change to the Git repository
Azure notices the commit, gets the latest code, builds it, and deploys it to some test environment
Azure runs my unit tests on the code, and fails the build if any tests fail
Azure runs my integration tests on the test environment, and fails the build if any tests fail
If all tests pass, promote the code to production
This seems like a logical pipeline to me but I've struggled to get it working.
I've managed to get to step 3. by creating two web apps, e.g. Muppet and MuppetStaging. The MuppetStaging environment is automatically updated on each commit, so that's a great start. I edited the deploy.cmd to perform unit tests. This fails the build when the unit tests fail. That's great too.
The integration testing is the hard bit. Before the deployment has been completed, I can't integration test the current build - because it's not been deployed yet. The best I could do was integration test the previous version... but not the pending version. And even if I could, how would I then promote a successful build to production?
I know there is a "staging slot" concept but I don't want to have to press a "Swap" button to get my change into production, that would defeat the concept of CD. There is also an "Auto Swap" but again I don't think this takes integration testing into account.
I've been looking at tutorials relating to this kind of issue but no-one seems to have my requirements exactly... so either it's not possible or I'm doing it all wrong.
let me see if i can help and answer some of your question.
The integration testing is the hard bit. Before the deployment has
been completed, I can't integration test the current build - because
it's not been deployed yet.
There is post deployment hook that trigger after everything is deployed but still within the deployment process.
https://github.com/projectkudu/kudu/wiki/Post-Deployment-Action-Hooks
There is also an "Auto Swap" but again I don't think this takes
integration testing into account.
if you do testing with post deployment hook, if test failed which will fail the deployment operation, "Auto Swap" shouldn`t be trigger. if it does please do file a bug in Project Kudu
Microsoft Release Management tools seems to apply to your problem perfectly. If you haven't tried these already you should. They are now available as a service and also works great with Azure. Use Visual Studio Team Services (previously known as Visual Studio Online) to use Release Management as a Service and use Git as version control system.
Check these resources:
1. Official RM Page
2. Visual Studio Team Services
3. Continuous Integration via VSTS