Background:
We are using the VSTS to build and Octopus integration to deploy our product. The Octopus step is configured as follows,
Issue
Today VSTS Build was throwing following error,
No supported agent found in pool Default. All agents in this pool are
using a version that is deprecated. Migrate to the latest 2.x version
of agent. For more information, see
https://go.microsoft.com/fwlink/?linkid=851067
As a result, the Agent was updated to the latest version,
After the update the octopus step stopped working with following error,
Then issue seems to be the environment variables are not replaced in the step.
I would like to know if there is a work around to fix this issue.
First, there is 2.* version available, so you can delete the old one and add the new one.
Secondly, use $(Build.BuildNumber) instead in Package Version input box, also for Output path: $(Build.ArtifactStagingDirectory).
Related
We have an on-premises Azure DevOps 2019 server, with build pipelines for numerous .Net 4.x solutions that our small team maintains using VS2019.
The team is about to upgrade to VS2022, and at some point I would like to migrate some solutions to .Net 6. Can DevOps 2019 build .Net 6 solutions, and if so what changes are needed to support this (such as presumably installing VS2022 on the server)?
Will those solutions' build pipelines require any changes or should they continue to work as-is? They don't contain anything too clever, with steps such as: NuGet restore, build solution, run unit tests, NuGet pack & push. (The build pipelines are managed via the web GUI, not YAML, if that makes a difference).
Some solutions will remain .Net 4.x, so the server will still need to support (build) these.
You should just need two things:
First you have to install the corresponding SDK for building the apps (see sdk download - Build apps - SDK) on your build-agents.
(Optional) Add or modify your set SDK Task in your pipelines (see use dotnet core task).
One more hint, you don't need to install a whole VS on the server. The Build-Tools are enough (VS2022 Buildtools preview).
I am creating an MSI installer with Wix and wrote a task in the azure DevOps pipeline which builds the MSI solution file using MSBuild. When the code is pushed to remote the pipeline runs the task but my task returns the error saying WiX toolset is not installed hence the build fails. Though it is assured that the MSBuild task works as it is building other projects in the solution.
##[error]Process 'MSBuild.exe' exited with code '1'.
##[error][Path to wixproj](44,5): Error : The WiX Toolset v3.11 (or newer) build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/
Is there any way to install Wix toolset using pipeline?
Or any workaround which might help?
Please note that I am using a custom job pool if that might be a cause for this issue.
Check this article from the official wix documentation.
Most likely, the issue is that your .wixproj is out of date and thus does not handle the breaking changes made in MSBuild 2017. You can re-create your .wixproj using the latest templates in Visual Studio or walk through the steps laid out here.
Essentially, you need to update the way that MSBuild imports the wix.targets because MSBuild 2017 changed the way they did that.
I've installed the latest VS Build Tools (2022), but my on-prem build agent isn't picking up the VisualStudio-related capabilities. I've been under the impression that we no longer need to install the full application in order to get these capabilities.
An example from this blog post:
I've added all workloads to my offline layout, and I've included them in my installation.
I know this is possible, because earlier I accidentally included Python and VS 2019 Build Tools in my Node.js installation configuration. The VS-related capabilities were found by the agent then.
But I'm trying to get 2022, so I uninstalled 2019.
How can I get the 2022 VS-related capabilities to be installed and detected by my build agent, without installing the full Visual Studio product?
You need to upgrade the agent to a recent enough version. You can download the agent from the azure-pipelines-agent repository's releases page. Or manually specify the capabilities.
You may need to set a special environment flag on the agent to prevent it from automatically being downgraded to whatever version shipped with your version if Azure DevOps Server or Team Foundation Server.
And then you'll also need to install the latest version of the vsbuild/msbuild and vstest tasks
Required agent version
You will need to install the most recent agent from the azure-pipelines-agent repository for it to auto-detect Visual Studio 2022, or alternatively add the capabilities to the agent manually.
You may need to force Azure DevOps Server to not downgrade back to its preferred agent version. You can do so by setting the following environment variable at the system level on your server before launching the agent:
AZP_AGENT_DOWNGRADE_DISABLED=true
These tricks will work for most tasks in the azure-pipelines-tasks repository, as long as it doesn't depend on a UI extension or service connection type that isn't available in your version of Azure DevOps Server.
https://jessehouwing.net/adding-visual-studio-2022-to-azure-devops-server-2020/
I have some problem with self-hosted Integration Runtime in Azure Data Factory V2.
I have a few VMs running 4.X.X IR software. Some of them had auto update enabled in DFv2
There was an update from 4.X.X to 5.X. After this, IR is unavailable from DFv2.
Looks like the IR services running on the VMs are pointing to a wrong execute path - using still 4.0. I can fix it manually with sc config or reinstall IR, but after reboot it doesn't work again.
Is that a bug? Can I somehow fix it without removing the VMs?
Update:
What I did - I went to Data Factory V2 Integration Runtimes and picked my self-hosted IR, went to Auto update and enabled it. My Virtual Machine hosting this IR was running an older IR software (4.X.X). There was an update to 5.X.X. Everything was working fine until I rebooted the VM. After this from Data Factory V2 Integration Runtimes I was seeing an error saying that my self-hosted IR is unavailable. I logged into the hosting VM and it turned out that IR software cannot start its service dmgsvc.exe. When you go to services.msc and check the Integration Runtime service pointing to the dmgsvc.exe, the path will be incorrect. What was wrong there? It was a catalog 4.0 instead of 5.0. IR software cannot start up correctly because of that and the error is Error 2: System cannot find the file specified. So what I did? I manually fixed it and it was working. But after the first reboot of the VM it was again pointing to the 4.0 catalog. I reinstalled the software and the effect was the same.
For the upgrade to version 5.x of the Azure Data Factory self-hosted integration runtime, we require .NET Framework Runtime 4.7.2 or later. On the download page, you'll find download links for the latest 4.x version and the latest two 5.x versions.
If automatic update is on and you've already upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime will be automatically upgraded to the latest 5.x version.
If automatic update is on and you haven't upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime won't be automatically upgraded to the latest 5.x version.
The self-hosted integration runtime will stay in the current 4.x
version. You can see a warning for a .NET Framework Runtime upgrade
in the portal and the self-hosted integration runtime client.
Refer: Troubleshoot self-hosted integration runtime
We have a CD/CI Azure DevOps build pipeline that stop working all of a sudden today. It has been invoked successfully in our pipeline for months on end.
The component that fails is the "npm install" , it fails with the following error in the verbose log:
I google around and some suggested to run: npm cache clear --force prior to npm install.
I tried that but same error persists.
Then I look up earlier in the log and see the following:
I tried to browse to https://github.com/sass/node-sass/releases/download/v4.12.0/win32-x64-83_binding.node and got the message "Page not found".
I cannot tell if this is related to the root cause why npm fails but it seems to back my assumption that something is not right with "npm install" as of this time of writing (Nov 17, 2020).
Anyone else using Azure DevOps for CD/CI having the same issue?
I look at NPM incident page and see this issue https://status.npmjs.org/incidents/r1tlhscrw3r6 but it should have been fixed.
Recently, a breaking change was made to the default Azure DevOps agent images for the default version of Node.js. It was incremented from 12.x to 14.x.
Breaking changes
Default version of Node.JS on images will be updated
from 12.x to 14.x
Target date
For Windows, Ubuntu images, rollout of this change will
start on 2 November 2020 and will take 3-4 days For MacOS images,
rollout will start on 9 November.
The motivation for the changes
On images, we always install LTS
version of Node.JS by default. On 2020-10-27, Node.JS 14 has become
LTS version. On 2020-11-30, Node.JS 12 will be switched to Maintenance
mode.
Possible impact
If you rely on default Node.JS version and your
project is not compatible to Node.JS 14, it might start to fail
Mitigation ways
Please consider using Node.js Tool Installer task (for Azure DevOps) and
setup-node (for GitHub Actions) to switch back to Node.JS 12.
Switching will take less than a second. Node.JS 12 still will be
available on images along with Node.JS 8, 10.
Based on #Matt's answer, I'll post the fragment of yml you need to fix this:
- task: NodeTool#0
inputs:
versionSpec: '12.x'
For anyone still using the graphical UI rather than YML files, you would add a
"Node.js tool installer" task and configure its version. It would look something like this (where the Version Spec contains the version of node.js you want run):
Also note that it is BEFORE the "npm install" task!!