Run powershell build step in VSTS agent installed on mac? - powershell

I installed VSTS build agent on mac to build xamarin iOS project. Builds worked fine until I added powershell build step.
Even though I installed powershell for mac (https://github.com/PowerShell/PowerShell) and re-installed the agent, VSTS complains it does not have agent that is capable to run the build.
No agent could be found with the following capabilities:
DotNetFramework, Xamarin.iOS, npm
When I disable the build step, builds work just fine.
Is it possible to run powershell build step on Mac?

As MrHinsh clarified, the PowerShell task cannot be used on Mac.
As a workaround I used ShellScript task:
With the following bash script:
#!/bin/bash
powershell ./SetAppVersion.ps1
Also, the powershell installer did not seem to add powershell to my PATH so I had to add it:
$ export PATH=$PATH:/usr/local/microsoft/powershell/6.0.0-alpha.16

If you're sure that DotNetFramework is installed then you can go to the Agent Queues settings and add a custom Capability to it called exactly that.
That should allow it to run but it might fail after that if the agent can't actually find them, but it might also succeed so it's probably worth a try.

No, you can't use a PowerShell task on a Mac, only node tasks are supported.
PowerShell tasks as currently written in PowerShell3 which is not supported on Mac. You can request that the team implement this on http://visualstudio.uservoice.com

In TFS build go to Agents Queues=>Capablilities=>Add variable named as DotNetFramework and give value for mac agent's dotnet framework path.
It's fix for the issue "No agent could be found with the following capabilities:DotNetFramework"

This is a follow-up to the accepted answer to address a question in a comment which I also had.
Thanks to spatialguy for posting and finding a simple solution to this problem. I had the same problem as KeithA45:
QUESTION: What if you wanted to do the same, but also pass arguments to the Bash script which passes them to the Powershell script?
I found a solution to this, first off, I modified the shell script task to include the Visual Studio Team Services (VSTS) environmental variables that I wanted to pass to the powershell script.
Next, I pass the arguments through to the called powershell script by slightly modifying the shell script mentioned by the accepted answer.
#!/bin/bash
powershell ./Version.ps1 $1 $2
Finally, in the powershell script, I catch the arguments that have been passed through using using param like this:
param([string]$version, [string]$path)
Wherein I can now use the variables $version and $path which contain the original arguments entered in VSTS to the needs of my powershell script.

Things seem to have moved forward because I ran successfully today a PowerShell#2 task on a Mac Self-Hosted Agent from an Azure DevOps build pipeline.
By checking "Enable system diagnostics" when queuing the build, the log shows me that the task found itself the path to the PowerShell Core (pwsh) that I installed on my Mac with the help of Homebrew (brew cask install powershell - see https://learn.microsoft.com/fr-fr/powershell/scripting/install/installing-powershell-core-on-macos).

Related

cannot update the powershell task version on azure devops pipeline

​when I am creating a build or a release the PowerShell task only allows me to choose between versions 1* and 2*. I have installed more recent versions of PowerShell on the build agents and I have also added it as a capability on the agents but I still see only versions 1* and 2*. so can you please help me?
That's not the PowerShell version, it's the PowerShell task version. Azure DevOps build/release tasks are versioned, and that version is completely unrelated to the version of PowerShell.
To use a different version of PowerShell, just make sure the PATH environment variable on the agent is pointing to the correct version of powershell.exe. If you want to use PowerShell Core (pwsh), set the pwsh flag to true. Refer to the documentation.

Debug Azure Devops powershell scripts locally in VSCode

Judging from the Debugging Azure Functions https://learn.microsoft.com/en-us/azure/azure-functions/functions-debug-powershell-local, it looks possible. Can somebody post a detailed example?
Let's say we have pipeline that run the Build.ps1. The script installs other PS modules builds my Visual studio solution and creates the installer.
The installer part breaks so I guess I have to use a Wait-Debugger before it and try to somehow attach to the agent powershell process. But oi am not certain how to do it.

What's the best way to run a linqpad script from your release pipeline?

I have a linqpad script which we need to run as part of our release, from VSTS. Best way I can think of is to run this as a Powershell script. There seem to be 2 options to be able to do this
Linqpad's native lprun.exe
Linqpadless lpless.exe
The problem with these however is that I will have to install these on the Build/Release VMs for each environment, which is what I'm trying to avoid at the moment.
Linqpadless does distribute a nuget package but I don't know how to run that from powershell/release pipeline.
Has anyone done something similar. What's the best way to achieve this?
You can add three tasks in your build definition to do this:
Nuget Task to install linqpadless package:
Command Line task to run lpless.exe:
Command Line task to run the script generated by lpless.exe in last step:
If you want to use Powershell script, you just need to call these command in the script one by one.

VSTS Run Powershell Script on Mac with Parameters

I have a Xamarin.Forms project wherein the Android project is built in VSTS using a hosted build agent which runs a powershell script at run-time.
I need to run the same powershell script against the Xamarin.iOS which uses an On Premise Mac Build Agent. But how?
I found this answer and a comment under the answer also had the same question regarding parameters, so I am posting the solution here since the issue is slightly different and that question has an accepted answer.
First off, I installed powershell on the mac using these instructions and I modified the shell script task to include the Visual Studio Team Services (VSTS) environmental variables that I wanted to pass to the powershell script.
Next, I pass the arguments through to the called powershell script by slightly modifying the shell script mentioned by the referenced answer.
#!/bin/bash
powershell ./Version.ps1 $1 $2
Finally, in the powershell script, I catch the arguments that have been passed through using using param like this:
param([string]$version, [string]$path)
Wherein I can now use the variables $version and $path which contain the original arguments entered in VSTS to the needs of my powershell script.

Nuget Command-line install is not launching Install/Init scripts

I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.