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

['Gavin Mogan' via Jenkins Developers]

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

On Fri., May 28, 2021, 8:14 a.m. Tony Noble,  wrote:

> "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 
> 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
>>  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  wrote:
>>
>>> On Fri, May 21, 2021 at 5:51 PM Tim Van Holder 
>>> 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.
>>>
>>> --
>>> 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
>>> 
>>> .
>>>
>> --
>> 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
>> 

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

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


On Tue, May 25, 2021 at 11:42 PM Tim Van Holder 
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
>  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  wrote:
>
>> On Fri, May 21, 2021 at 5:51 PM Tim Van Holder 
>> 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.
>>
>> --
>> 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
>> 
>> .
>>
> --
> 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
> 
> .
>

-- 
You 

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

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


On Mon, 24 May 2021 at 17:40, Jesse Glick  wrote:

> On Fri, May 21, 2021 at 5:51 PM Tim Van Holder 
> 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.
>
> --
> 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
> 
> .
>

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

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

[Jesse Glick]

On Fri, May 21, 2021 at 5:51 PM Tim Van Holder 
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.

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

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

-- 
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--BPf7BXEtgPWbFX6-tX_UCjcz2AUb%3DC_mJrntRWTBr1SA%40mail.gmail.com.