"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. On Tue, May 25, 2021 at 11:42 PM Tim Van Holder <tim.vanhol...@gmail.com> wrote: > 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 <jgl...@cloudbees.com> wrote: > >> On Fri, May 21, 2021 at 5:51 PM Tim Van Holder <tim.vanhol...@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 >> <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 jenkinsci-dev+unsubscr...@googlegroups.com. >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--BZwB%2BL6T6SXvuat9QjVnB5STF3iX1qJLxPHbqfJQqgWw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAKMi--BZwB%2BL6T6SXvuat9QjVnB5STF3iX1qJLxPHbqfJQqgWw%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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9GoByXwyrjukHTxdCNMhzXTp%2BJ3CiMHEADJd_7XuUJNVA%40mail.gmail.com.
