VSTS Run Powershell Script on Mac with Parameters - powershell

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.

Related

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.

Run powershell build step in VSTS agent installed on mac?

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).

Powershell vs Console application for deployment

we have application that needs to simply copy somefiles from source to destination and manipulate config files based on the environment. We use Jenkins for deployment. Since i am comfortable with C# i thought of writing simple console application (.exe ) and invoke that exe on post-deployment by passing some command line argument. and i think this would work.
But i see people are recommending power-shell for deployment. and i have used PS for other projects for deployment.
i just wanted to know what powershell can do that windows console application cannot do?
Since PowerShell could be wholly embedded (not really the right term but it works for this explanation) in C# , there's nothing you could do in PowerShell that couldn't also be achieved in C#.
You can also embed C# in PowerShell, but for various reasons you don't get exactly the same scope of functionality that you can with an .exe.
The point of using PowerShell has to do with the context of it being part of a deployment step.
A PowerShell command or script is more easily changed. A build process is not required.
Its contents are more readily visible and readable to someone who wants to understand the process.
The code written will (likely) be less verbose, further making it easier to understand, and for deployment steps it may be much more straightforward to do those steps in PowerShell (a single cmdlet may do what would be several (dozen) lines in C#).

How to install Azure cmdlets using powershell

I'm trying to install Azure cmdlets using powershell, not the wizard provided by Microsoft.
That's because my script (which has Azure cmdlets) will be used in a new virtual machine located in Azure and if my script try to run some cmdlet of Azure, will fail for sure.
I would like to put the installation lines of the powershell cmdlets on the top of my script for install the whole cmdlets and after that, that my script execute the other cmdlets without problem.
So, anyone knows?
Thanks!
If you have the Web Platform Installer in the VM, you can use the script I posted at PowerShell Magazine.
http://www.powershellmagazine.com/2014/02/27/using-powershell-and-web-platform-installer-to-install-azure-powershell-cmdlets/
Or get the Windows Standalone installer from https://github.com/Azure/azure-sdk-tools/releases and use msiexec to install that.
If you want to use PowerShell to download the latest version too:
You can use Invoke-WebRequest to read the page (https://github.com/Azure/azure-sdk-tools/releases) and then get all links from that. You can then get all links that end with .msi and take the first link for download.
#Code not tested
$doc = Invoke-WebRequest 'https://github.com/Azure/azure-sdk-tools/releases'
$links = $doc.Links.Href

Where does Powershell and PSake execute msbuild from?

While making a build automation I came across an issue. Along with upgrading Visual Studio 2013, the path to MSBuild has moved as described here http://timrayburn.net/blog/visual-studio-2013-and-msbuild/
I've updated my system path to point to this new location for msbuild. Using a regular cmd prompt msbuild resolves just fine. But running my scripts in powershell, it seems to still pick up the old one, and showing the issue as described in the link. How can I see and change where powershell and psake picks up msbuild from, so I can point to the expected version?
PSake supports more MSBuild versions on one box. You can choose version and platform eg. 4.0x64 with framework directive. Path to MSBuild tools is not taken from $env:path but is computed. It uses registry to find proper path.
VS 2013 and MSBuild Tools are supported since PSake 4.3
In PS type [Environment]::GetEnvironmentVariable("Path")
Do you see both paths? In what sequence do they appear? What occurs in cmd vs ps when you switch the order?