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 <https://issues.jenkins.io/browse/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. On Mon, 24 May 2021 at 17:40, Jesse Glick <[email protected]> wrote: > On Fri, May 21, 2021 at 5:51 PM Tim Van Holder <[email protected]> > 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 > <https://github.com/jenkinsci/powershell-plugin/blob/master/src/main/java/hudson/plugins/powershell/PowerShellInstallation.java> > 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 <https://issues.jenkins.io/browse/JENKINS-28718>. A > dedicated block-scoped step makes sense for logic that does something more > complicated than bind a `ToolInstallation` to a `$PATH` entry. > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Q66ArFPTDY2V8eeQn3t4AR_8giQc%3DtsptoDX5n5e8aQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Q66ArFPTDY2V8eeQn3t4AR_8giQc%3DtsptoDX5n5e8aQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--BZwB%2BL6T6SXvuat9QjVnB5STF3iX1qJLxPHbqfJQqgWw%40mail.gmail.com.
