[workflow-durable-task-step-plugin] Add tool installer for Powershell Core

[Tim Van Holder]

There are several "shelly" steps (sh, bat, powershell and pwsh).

Of these, bat and powershell don't really need much configuration, because they come with Windows.

Similarly, any Linux will have a 'sh', although there I think it might be useful to be able to specify dash/bash/ksh/csh/... on the step.

(And a Windows machine might also have a sh executable.)

However, PowerShell Core is multi-platform and installable via zip or tarball.

As such, I'd be inclined to want to add a tool installer for it (I already have a crawler script ready for it).

The main question is: where to add it? Should I

a) file a PR for it on the workflow-durable-task-step-plugin (adding the Downloadable as well as the ToolInstaller), or

b) just make it a tiny separate plugin?

I'd be more inclined towards a), because it would enable a nice selection of the install to use on the snippet generator for the pwsh step. With b) you'd essentially only have the general tool section entry.

Either way, a withPwsh (or withPowerShellCore?) step would also make sense, to put a particular install in PATH for a delimited set of steps (as I understand it, with the tool section, it always applies to an entire stage).

[Jesse Glick]

On Fri, May 21, 2021 at 5:51 PM Tim Van Holder <tim.va...@gmail.com> wrote:

PowerShell Core is multi-platform and installable via zip or tarball.

As such, I'd be inclined to want to add a tool installer for it

The `ToolInstallation` system is generally deprecated. Modern CI setups are expected to use VMs or containers with appropriate tools preinstalled. So I would probably recommend creating a separate plugin for the likely small number of users who would benefit. Or better yet, just check whether the existing plugin works for you.

 

a withPwsh (or withPowerShellCore?) step would also make sense, to put a particular install in PATH for a delimited set of steps (as I understand it, with the tool section, it always applies to an entire stage)

There is limited flexibility in Declarative syntax. For Scripted syntax, this just sounds like it would be better covered by the general JENKINS-28718. A dedicated block-scoped step makes sense for logic that does something more complicated than bind a `ToolInstallation` to a `$PATH` entry.

[Tim Van Holder]

I'll have another look at that plugin - at first glance, it seems to have hardcoded assumptions on Windows vs Linux.

And the point here is to have tool installations for specific PowerShell (not Windows PowerShell) versions downloaded and deployed from GitHub releases, regardless of platform.

As for the build wrapper, the pwsh step seems to resist proper selection of which shell to run.

In a freestyle job, the wrapper works. But that's because it only has equivalents of bat and sh. Running pwsh from those uses the executable from the selected tool installation just fine.

However, in a pipeline, a pwsh step inside the wrapper seems to forcibly put "C:\Program Files\PowerShell\7" at the start of PATH, overriding what the wrapper put in place.

That feels broken to me - even using a tool section has no effect.

It would also be counterintuitive to have to use sh/bat steps to be able to use a tool-based pwsh installation (and the whole point of using a pwsh step would be to not have to care whether it's linux/osx/windows/...).

And yes, something like JENKINS-28718 would remove the need for more specific withXXX wrappers - but that proposal as-is seems to assume installation names are globally unique - and it is my understanding they're only unique within a particular installation type. For example, I might have both a PowerShell installation named 'LTS' and a .NET SDK installation named 'LTS', so "withTool('LTS') { }" would be ambiguous. Also, an installation's setup is not necessarily limited to just a home folder, so $(tool 'XXX') might only handle part of what's needed for a given tool.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Q66ArFPTDY2V8eeQn3t4AR_8giQc%3DtsptoDX5n5e8aQ%40mail.gmail.com.

[Tony Noble]

"The `ToolInstallation` system is generally deprecated."

Out of interest, how long has this been the case?  For a number of reasons, pre-built and configured VMs or containers have not been an option for us and the ability to make tools available on demand for development teams' builds is pretty key to the service we provide.

In an Enterprise environment with a lot of historical software (and years of technical debt that can't quickly be fixed), the availability of different versions of Maven, Ant, Java and similar for building is pretty important.  And pre-installing them on every single worker VM is simply not practical.  Similarly, neither is installing every new version of every tool on every VM.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--BZwB%2BL6T6SXvuat9QjVnB5STF3iX1qJLxPHbqfJQqgWw%40mail.gmail.com.

[Gavin Mogan]

I think it's deprecated in the same way freestyle is. Code isn't being removed just not the recommended solution.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9GoByXwyrjukHTxdCNMhzXTp%2BJ3CiMHEADJd_7XuUJNVA%40mail.gmail.com.