Yet another build helper for PowerShell - Invoke-Build
264 views
Skip to first unread message
Roman Kuzmin
Aug 22, 2011, 2:14:31 PM8/22/11
to psake-dev
Let me introduce yet another build helper for PowerShell (a standalone
script):
https://github.com/nightroman/Invoke-Build
It is similar to psake and ideas are borrowed from there but this is
not a clone or a fork in any way. Invoke-Build works well is some my
scenarios when psake does not. That is why the tool was created.
Hopefully, it can be useful for somebody else.
If psake developers will borrow some ideas from Invoke-Build then I
will be happy, too.
script):
https://github.com/nightroman/Invoke-Build
It is similar to psake and ideas are borrowed from there but this is
not a clone or a fork in any way. Invoke-Build works well is some my
scenarios when psake does not. That is why the tool was created.
Hopefully, it can be useful for somebody else.
If psake developers will borrow some ideas from Invoke-Build then I
will be happy, too.
Roman Kuzmin
Aug 29, 2011, 2:02:14 PM8/29/11
to psake-dev
The tool Invoke-Build matured enough in order to be called the first
release, v1.0.0. A few points of interest and differentiators:
* There are no special parameters and properties in build scripts.
Standard PowerShell parameters (param(...)) are used as parameters and
variables defined at the script level are used as properties. Both
parameters and values are available for tasks as $SomeVariable for
reading and $script:SomeVariable for writing. Tasks can create new
shared variables at the script scope as $script:NewVariableName = ...
* Invoke-Build tasks do not have separate -Depends and -Action
parameters. Instead, tasks have the -Jobs parameter where jobs are
either task names or script blocks (any number of both and any order
is allowed). Tasks and blocks are invoked in the order they are
specified. This approach seems to be simple and flexible at the same
time. In particular, tasks can be specified after code blocks (a new
concept) and this can be used, just for example, for implementing task
chains that can be started (e.g. restarted after a failure) at the
specified point. Trivial example:
http://stackoverflow.com/questions/3908602/how-to-start-a-script-at-a-specified-point-in-powershell/7215127#7215127
* Build scripts can be "classic" (called by Invoke-Build, similar to
psake) or "master" (they call Invoke-Build themselves). Master build
scripts have a couple of extra commands to be called but they are
regular PowerShell scripts, they are called directly with task list
and own parameters.
release, v1.0.0. A few points of interest and differentiators:
* There are no special parameters and properties in build scripts.
Standard PowerShell parameters (param(...)) are used as parameters and
variables defined at the script level are used as properties. Both
parameters and values are available for tasks as $SomeVariable for
reading and $script:SomeVariable for writing. Tasks can create new
shared variables at the script scope as $script:NewVariableName = ...
* Invoke-Build tasks do not have separate -Depends and -Action
parameters. Instead, tasks have the -Jobs parameter where jobs are
either task names or script blocks (any number of both and any order
is allowed). Tasks and blocks are invoked in the order they are
specified. This approach seems to be simple and flexible at the same
time. In particular, tasks can be specified after code blocks (a new
concept) and this can be used, just for example, for implementing task
chains that can be started (e.g. restarted after a failure) at the
specified point. Trivial example:
http://stackoverflow.com/questions/3908602/how-to-start-a-script-at-a-specified-point-in-powershell/7215127#7215127
* Build scripts can be "classic" (called by Invoke-Build, similar to
psake) or "master" (they call Invoke-Build themselves). Master build
scripts have a couple of extra commands to be called but they are
regular PowerShell scripts, they are called directly with task list
and own parameters.
Rob Reynolds
Aug 29, 2011, 2:27:04 PM8/29/11
to psak...@googlegroups.com
Speaking for myself and not for psake, please do not post about a tool that is in competition to psake on psake's development group. I consider it bad form and moreover, it's rude.
The first email was forgivable, but continuing to talk about your tool on a forum that is clearly not for your tool shows quite a bit of disrespect for those that have worked hard on psake and will likely guarantee that those that may have been interested in the beginning (like me) will now pass on looking at your tool.
-Rob
--
You received this message because you are subscribed to the Google Groups "psake-dev" group.
To post to this group, send email to psak...@googlegroups.com.
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psake-dev?hl=en.
Message has been deleted
Rob Reynolds
Aug 29, 2011, 3:02:39 PM8/29/11
to psak...@googlegroups.com
Thinking about this a bit more - the first email was fine because it mentioned something that would work where psake does not and works somewhat like psake. There is also a link with more information. It's really the second email that prompted my reply. If someone had asked for more information or something then that would be a different story. No worries...
Roman Kuzmin
Aug 29, 2011, 3:18:43 PM8/29/11
to psake-dev
Hi Rob,
Thank you for your honest replay. I see your point and partially
agree. The goal of my both posts was not competition but hope that
some ideas (psake ideas) evolved in Invoke-Build can migrate back to
psake and make it even better.
On Aug 29, 8:02 pm, Rob Reynolds <ferventco...@gmail.com> wrote:
> Thinking about this a bit more - the first email was fine because it
> mentioned something that would work where psake does not and works somewhat
> like psake. There is also a link with more information. It's really the
> second email that prompted my reply. If someone had asked for more
> information or something then that would be a different story. No worries...
>
>
> - Show quoted text -
Thank you for your honest replay. I see your point and partially
agree. The goal of my both posts was not competition but hope that
some ideas (psake ideas) evolved in Invoke-Build can migrate back to
psake and make it even better.
On Aug 29, 8:02 pm, Rob Reynolds <ferventco...@gmail.com> wrote:
> Thinking about this a bit more - the first email was fine because it
> mentioned something that would work where psake does not and works somewhat
> like psake. There is also a link with more information. It's really the
> second email that prompted my reply. If someone had asked for more
> information or something then that would be a different story. No worries...
>
> On Mon, Aug 29, 2011 at 1:27 PM, Rob Reynolds <ferventco...@gmail.com>wrote:
>
>
>
> > Speaking for myself and not for psake, please do not post about a tool that
> > is in competition to psake on psake's development group. I consider it bad
> > form and moreover, it's rude.
>
> > The first email was forgivable, but continuing to talk about your tool on a
> > forum that is clearly not for your tool shows quite a bit of disrespect for
> > those that have worked hard on psake and will likely guarantee that those
> > that may have been interested in the beginning (like me) will now pass on
> > looking at your tool.
>
> > -Rob
>
>
>
>
> > Speaking for myself and not for psake, please do not post about a tool that
> > is in competition to psake on psake's development group. I consider it bad
> > form and moreover, it's rude.
>
> > The first email was forgivable, but continuing to talk about your tool on a
> > forum that is clearly not for your tool shows quite a bit of disrespect for
> > those that have worked hard on psake and will likely guarantee that those
> > that may have been interested in the beginning (like me) will now pass on
> > looking at your tool.
>
> > -Rob
>
> > On Mon, Aug 29, 2011 at 1:02 PM, Roman Kuzmin <nightro...@gmail.com>wrote:
>
> >> The tool Invoke-Build matured enough in order to be called the first
> >> release, v1.0.0. A few points of interest and differentiators:
>
> >> * There are no special parameters and properties in build scripts.
> >> Standard PowerShell parameters (param(...)) are used as parameters and
> >> variables defined at the script level are used as properties. Both
> >> parameters and values are available for tasks as $SomeVariable for
> >> reading and $script:SomeVariable for writing. Tasks can create new
> >> shared variables at the script scope as $script:NewVariableName = ...
>
> >> * Invoke-Build tasks do not have separate -Depends and -Action
> >> parameters. Instead, tasks have the -Jobs parameter where jobs are
> >> either task names or script blocks (any number of both and any order
> >> is allowed). Tasks and blocks are invoked in the order they are
> >> specified. This approach seems to be simple and flexible at the same
> >> time. In particular, tasks can be specified after code blocks (a new
> >> concept) and this can be used, just for example, for implementing task
> >> chains that can be started (e.g. restarted after a failure) at the
> >> specified point. Trivial example:
>
> >>http://stackoverflow.com/questions/3908602/how-to-start-a-script-at-a...
>
> >> The tool Invoke-Build matured enough in order to be called the first
> >> release, v1.0.0. A few points of interest and differentiators:
>
> >> * There are no special parameters and properties in build scripts.
> >> Standard PowerShell parameters (param(...)) are used as parameters and
> >> variables defined at the script level are used as properties. Both
> >> parameters and values are available for tasks as $SomeVariable for
> >> reading and $script:SomeVariable for writing. Tasks can create new
> >> shared variables at the script scope as $script:NewVariableName = ...
>
> >> * Invoke-Build tasks do not have separate -Depends and -Action
> >> parameters. Instead, tasks have the -Jobs parameter where jobs are
> >> either task names or script blocks (any number of both and any order
> >> is allowed). Tasks and blocks are invoked in the order they are
> >> specified. This approach seems to be simple and flexible at the same
> >> time. In particular, tasks can be specified after code blocks (a new
> >> concept) and this can be used, just for example, for implementing task
> >> chains that can be started (e.g. restarted after a failure) at the
> >> specified point. Trivial example:
>
>
> >> * Build scripts can be "classic" (called by Invoke-Build, similar to
> >> psake) or "master" (they call Invoke-Build themselves). Master build
> >> scripts have a couple of extra commands to be called but they are
> >> regular PowerShell scripts, they are called directly with task list
> >> and own parameters.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "psake-dev" group.
> >> To post to this group, send email to psak...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> psake-dev+...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/psake-dev?hl=en.- Hide quoted text -
> >> * Build scripts can be "classic" (called by Invoke-Build, similar to
> >> psake) or "master" (they call Invoke-Build themselves). Master build
> >> scripts have a couple of extra commands to be called but they are
> >> regular PowerShell scripts, they are called directly with task list
> >> and own parameters.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "psake-dev" group.
> >> To post to this group, send email to psak...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> psake-dev+...@googlegroups.com.
> >> For more options, visit this group at
>
> - Show quoted text -
Reply all
Reply to author
Forward
0 new messages