Git repo update

[James Kovacs]

Hi, Everyone,

During the initial import from SVN to Git, I got one of the committer's email addresses wrong. I corrected the issue using this technique:

http://coffee.geek.nz/how-change-author-git.html

The good news is that it is fixed. The bad news is if you already pulled or forked the repo, you'll have duplicate commits. (Found this out after the fact. I'm a git noob.) The easiest solution is to delete your old repo and just pull down a fresh copy. Apologies if I've caused anyone grief.

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - Solutions Architect
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[Jorge Matos]

James,

 

Any thoughts on the psake-ps2 branch?  I know you'd like to be backwards compatible with PowerShell V1 but it seems that there's so much goodness in PowerShell V2 that being backwards compatible doesn't make much sense to me.  I propose we keep a branch for PS V2 for the time being and when new features are added, they are added to the master and to the PS V2 branch.  I think at some point we should merge the branch into the master and remove the branch, we can still provide a link to the PS V1 version of psake for those folks who haven't switched to V2.

 

Thoughts?

[James Kovacs]

I polled folks awhile back asking how important PS V1 compatibility is. I didn't receive a great deal of responses, but everyone who responded didn't mind taking a dependency on V2 and no one cried out that they needed V1 compatibility. And that was when PS V2 was in beta. Now that PS V2 has been released, I think there is even less need for V1 compatibility.

What is the current state of the psake-ps2 branch? It is simply the old Jorge branch renamed. So I suspect that you (Jorge) have the best idea of where it's at. If it's stable, I'd be happy to see it merged into master with a branch/tag created for V1 support for those who need it.

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - Solutions Architect
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[Eric Hexter]

I am totally cool with PS2 as I am developing on Win 7.  I do have a question as to what the PS2 branch would include as far as a feature set.  If psake is kept lightweight, what can psake do with ps2 that it cannot do with ps1?

 

Eric Hexter

Principal Consultant | Headspring Systems | www.HeadspringSystems.com
email | ehe...@HeadspringSystems.com
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter

[Jorge Matos]

Yes, its very stable, I've been using it in a production environment since April.  I've used it for project builds and for simple integration tasks that move data around between the DB and web services.

 

The main difference is that it has been re-written as a module that contains advanced functions.  Someone using the module could either run the import-module command with the path to the module file (i.e. import-module .\psake.psm1) or (my preference) you can copy the psake.psm1 into a folder called psake into the "Modules" folder in your profile directory (you may have to create it if it's not there) or your machine-wide "Modules" directory:

 

i.e. Profile Directory:

C:\Users\Jorge\Documents\WindowsPowerShell\Modules\psake

 

i.e. Machine-wide Modules folder:

 

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\psake

 

Once the psake folder is created and you've copied the psake.psm1 file into it - restart PS and type "import-module psake" - PS will find the

module and load it automatically.  What I've done is add the "Import-Module psake" to my profile script so that it is loaded everytime I startup PS.

 

Module Benefits:

1) Build scripts don't need to know where psake is installed, they just call Run-psake and it works.

2) Encapsulation - Global variables are no longer required since they can be private to a module unless explicitly exported (I haven't gotten around to actually changing the psake code to not use global variables yet)

3) Modules can be unloaded if needed which removes all the code and variables from memory

 

Advanced Functions:

The other big difference is that the "Run-psake" and "Task" functions have been converted into Advanced Functions which basically means you can take advantage of comment help which means you can type help run-psake and you will get back real help with examples.  

 

Minor changes:

1) Coding style is different

2) Try/Catch is used instead of the "Trap" statement

3) Got rid of the "exec" function

4) You can now define "Pre" and "Post" actions for a task

5) You can define how the task name will be formatted

6) You can define a "TaskSetup" function that will be executed before every task (took that from NUnit)

7) You can define a "TaskTearDown" function that will be executed after every task (took that from NUnit too)

8) Create a global variable called "psake_buildSucceeded" that will be set to true if the build succeeds - scripts can check this

9) Also added a "$noexit" switch to Run-Psake so that the function will not use the exit() function so that you can test a build script at the

command line without PS closing down (the default behavior when the build fails is to call exit(1) so that the calling code can determine if the build failed or not)

10) The psake-buildTester.ps1 had to be changed slightly in order for it to call the Run-psake function

11) Added more examples in the .\examples folder for POST conditions, PRE and POST Actions, etc..

 

Changes I'd like to make:

1) Change all global variables to local variables

2) Convert all the functions into Advanced Functions so that we can provide better help

3) Remove the "Notes" section from the help or update it so that credit is given to all the psake contributors (right now it just has my name because I used a script to generate a template for me)

4) Consider using exported module variables to influence the behavior of psake (I.e. $psake_use_exit_when_build_fails) so that the $noexit parameter is not required

5) Change Run-psake to something that fits with the list of approved PS verbs (try get-verb and you should get a list of approved verbs) 

maybe "Invoke-psake", "Start-psake", etc..?  If we continue to use "Run-psake" then we'll get this message every time the module is loaded into PS:

"WARNING: Some imported command names include unapproved verbs which might make them less discoverable.  Use the Verbose
 parameter for more detail or type Get-Verb to see the list of approved verbs."

 

I then ran the import-module command with the -verbose parameter and found out that PS doesn’t like the "Run-psake"  function name:

 

PS C:\users\jorge\Documents\Projects\psake-jorge> import-module .\psake.psm1 -verbose
VERBOSE: Importing function 'FormatTaskName'.
VERBOSE: Importing function 'Include'.
VERBOSE: Importing function 'Properties'.
WARNING: Some imported command names include unapproved verbs which might make them less discoverable.  Use the Verbose
 parameter for more detail or type Get-Verb to see the list of approved verbs.
VERBOSE: The command name 'Run-psake' includes an unapproved verb which might make it less discoverable. The suggested
alternative verbs are "Invoke, Start".
VERBOSE: Importing function 'Run-psake'.
VERBOSE: Importing function 'Task'.
VERBOSE: Importing function 'TaskSetup'.
VERBOSE: Importing function 'TaskTearDown'.

 

 

James - please merge it into the master like you recommended, provided you don't see any issues with the changes I've made or plan to make. 

 

If anyone in the group has any questions or concerns after reviewing the code - Please let me know.

 

Thanks!

 

P.S.

Forgive me if I've explained the obvious regarding modules or advanced functions, I don't want to assume that everyone's had time to play with all the new PS features.

[Eric Hexter]

Thanks for the detailed explanation.  I am a n00b to powershell so the details of the differences are appreciated.

 

The idea of pre and post conditions are interesting but I have found that their use in the test frameworks have turned out to be problematic. In fact xUnit team decided to leave them out of their framework, which was a pretty interesting take on the need for them.  Couldn't the dependency chain accomplish the Pre condition?   The post condition is interesting because  you really cannot do that with the dependency chain, but it seems like it would be more noise and potentially harder to trace than just setting up top level targets which clearly spell out the order of execution.

 

Having a top level task that is only used to setup the order of execution seems like a pretty clear way for developers new to a build script to understand what is happening and how to add or remove/reorder tasks in a build.

 

Task privateBuild -dependencies Clean, Compile, AspNetCompile, UnitTests, RebuildDatabase, IntegrationTests, ResetManualTestData, Inspection, Package

 

I am not shooting down the idea of pre and post conditions I just want to understand the context of how you got to adding them and what problem they solve.

 

Eric

[Jorge Matos]

Eric,

I wasn't trying to solve a specific problem and please don't worry about "shooting down my ideas" - I'm not afraid to call my baby ugly!
I added pre and post conditions after getting exposed to "Design By Contract" http://en.wikipedia.org/wiki/Design_by_Contract and reading Bertrand Meyer's book "Object-Oriented Software Construction".  I like the dependency chain pattern but it seemed to lack the ability to optionally execute a task ("pre") and the ability to verify whether a task did what it said it would do ("post").

The following psake script is one of my backend production scripts, but it's been edited to protect the innocent :

properties {
    $destinationDir = "destinationDirdir"
    $workingDir = "workingDir"
    $backupDir = "workingDir\backup"
}

task default -depends CalcDates, BackupFiles, CreateCatalogs, CopyCatalogs

task CalcDates{   
}

task BackupFiles -depends CalcDates -precondition { return (dir $workingDir\*.xml) -ne $null } -action{   
}

task CreateCatalogs -depends BackupFiles {
}

task CopyCatalogs -depends CreateCatalogs {   
}

The BackupFiles task does not do anything unless there are actually any xml files to backup.  I could have added an "if" statement to the body of the BackupFiles files task, but it seemed cleaner to me to have the precondition since the code in the task would be dedicated to just backing up the xml files.  It's a preference thing.

I hope this example makes it clearer.  I am concerned about "Noise" and would suggest that any pre or post condition be kept short (1 line ideally) to minimize the "Noise", but overall I vote to keep pre and post conditions, but I'm open to hearing from others in the group about this.

Please feel free to ask questions and don't worry about stepping on my toes Eric - I like feedback!

P.S.
We've met before at the Austin .NET user group haven't we?
Stephen says "Hi" 

--
Jorge Matos
Senior .NET Architect, MCSD.NET, MCSD Visual Studio 6.0
(440) 666-3107
jma...@bennettadelson.com    
matos...@hotmail.com      
Blog: http://jorgelmatos.blogspot.com
--------------------------------------------------------------------------------
BENNETT ADELSON
Microsoft Solution Center
6050 Oak Tree Blvd. Suite 150
Cleveland, Ohio 44131
(216) 369-0140
www.bennettadelson.com
--------------------------------------------------------------------------------
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to
move in the opposite direction."... - Albert Einstein
--------------------------------------------------------------------------------

[Eric Hexter]

Ah yes we have met, I did not recognize your name from the original email.

 

Thanks for the context around what you are doing with this.  It does make sense in the example you gave for the pre condition.  I was thinking this was being used for more of what I could consider a software build process rather than a general system automation process.

 

I am not so much for or against the pre/post conditions, I just wanted to understand what got you to the point of adding them to psake.  I do not think I would use them but as long as it did not bloat the main script I am pretty neutral to having the feature.

 

I think the ability for psake to work with the built in help system is pretty important.  One of the things I have heard over and over again is for powershell to force a convention to make scripts more discoverable, which means for those who are experience in ps, it is pretty simple for them to get in and understand how to use it from the help system rather than digging into the source.

 

Eric Hexter

Principal Consultant | Headspring Systems | www.HeadspringSystems.com
email | ehe...@HeadspringSystems.com
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter

[Patrick]

Hi All

I've been using Psake v2 for about 3 months now and found it pretty
stable. I have made some changes to it though. Some comments below.

On Sep 25, 8:33 pm, "Jorge Matos" <matos.jo...@gmail.com> wrote:
>
> The main difference is that it has been re-written as a module that contains advanced functions.  Someone using the module could either run the import-module command with the path to the module file (i.e. import-module .\psake.psm1) or (my preference) you can copy the psake.psm1 into a folder called psake into the "Modules" folder in your profile directory (you may have to create it if it's not there) or your machine-wide "Modules" directory:
>
> i.e. Profile Directory:
> C:\Users\Jorge\Documents\WindowsPowerShell\Modules\psake
>
> i.e. Machine-wide Modules folder:
>
> C:\Windows\System32\WindowsPowerShell\v1.0\Modules\psake
>
> Once the psake folder is created and you've copied the psake.psm1 file into it - restart PS and type "import-module psake" - PS will find the
> module and load it automatically.  What I've done is add the "Import-Module psake" to my profile script so that it is loaded everytime I startup PS.

Mmm I'm now finding that the machine-wide folder causes problems when
you want to update things. In our case I'm going to try to move the
Psake module to a tools directory in the repository so that I only
have to update that one. However the whole modules thing does still
work given that my scripts can simply do an Import-Module with the
right name and things are sorted.

>
> Changes I'd like to make:
> 1) Change all global variables to local variables

I emailed the user group a while back with a copy of the psake script
I'm using. In that script I removed a whole lot of global variables so
that I could support nested (or hierarchical) build scripts. The
original version of Psake would allow scripts to clobber each others
Psake variables because the variables were all global. This would only
happen if one build script called another build script (which happens
in my builds quite frequently because I have a global build script to
control the individual module build scripts). Feel free to use my
version as a suggestion or to just use the entire script or ...

> 5) Change Run-psake to something that fits with the list of approved PS verbs (try get-verb and you should get a list of approved verbs)
> maybe "Invoke-psake", "Start-psake", etc..?  If we continue to use "Run-psake" then we'll get this message every time the module is loaded into PS:
> "WARNING: Some imported command names include unapproved verbs which might make them less discoverable.  Use the Verbose
>  parameter for more detail or type Get-Verb to see the list of approved verbs."

I have just changed Run-psake to Invoke-psake to stop that specific
error, so my vote goes out to that ;)

Currently at work I have some time to work on our build and testing
system (which uses Psake as the build tool) so I'm planning to have
another look at Psake to see if there's anything else I can improve.
Currently I find the error messages (in case of build failure) very
useless and I'd like to improve them. Also I'd like to get the timing
to always show up (not just when the build succeeds).

Finally a long term goal it to get Psake to properly support nested /
hierarchical builds. It would be best if each build would run inside
it's own runspace / appdomain / process while still being able to pass
on the console output to the originating powershell console.
Unfortunately I haven't been able to figure out how to accomplish
those two things at the same time. I could probably make it work by
writing some C# code but that would defeat the purpose ;)

Anyway thanks for reading my ramblings.

Regards

Patrick

[Jorge Matos]

Patrick,

Good comments! 

I agree with you that using a module that is loaded in your machine profile does mean that if you update psake that you need to make sure any build scripts using it on that machine still work.  Hopefully we won't be making breaking changes too often, but I think the next commit I make will cause existing build scripts to break because I am changing the name of the "Run-psake" function to "Invoke-psake".

Changing all the psake global variables to "script" scope might make running nested builds easier to do.  Capturing build output is easy as long as you don't use write-host in your tasks.  I'll have to try a nested build once I'm done.

I like your idea about always having the timing show up, that makes sense.  I'll take another look at the error messages, and see if they can be improved. 

[Jorge Matos]

Eric,

I hear you about the help, I'm working right now to make most of the psake functions into advanced functions (task, properties, et...) so that they will be integrated with the help system.  You will be able to "type help task -full" and learn everything you need about how to use the task function.