psake - Project Hosting on Google Code

Older Nov 13, 2009 issue 6 (Support for CCNET) commented on by suhinini - James, do you have in plans full CCNet integration? Thanks James, do you have in plans full CCNet integration? Thanks Oct 26, 2009 issue 9 (Failed build still runs tests) commented on by aaronlerch - I know it's been a while, but I just wanted to say that this was probably the stickiest thing to figure out with psake (why my build succeeded when it really failed). Some documentation would go a looong way. :) Other than this, it's great so far, for a small project! I know it's been a while, but I just wanted to say that this was probably the stickiest thing to figure out with psake (why my build succeeded when it really failed). Some documentation would go a looong way. :) Other than this, it's great so far, for a small project! Oct 14, 2009 psake-v2.01.zip (psake v2.01) file uploaded by james.kovacs - Labels: Type-Archive Featured Labels: Type-Archive Featured Oct 14, 2009 psake-v2.01.zip (psake v2.01) file uploaded by james.kovacs - Labels: Type-Package Featured Labels: Type-Package Featured Oct 03, 2009 psake-v2.00.zip (psake v2.00) file uploaded by james.kovacs - Labels: Featured Type-Archive Labels: Featured Type-Archive Oct 03, 2009 psake-v1.00.zip (psake v1.00) file uploaded by james.kovacs - Labels: Featured Type-Archive Labels: Featured Type-Archive Oct 03, 2009 r39 (Source moved to GitHub: git://github.com/JamesKovacs/psake.g...) committed by james.kovacs - Source moved to GitHub: git://github.com/JamesKovacs/psake.git Source moved to GitHub: git://github.com/JamesKovacs/psake.git Oct 02, 2009 r38 (1) Renamed Run-psake to Invoke-psake 2) Timing report is alw...) committed by matos.jorge - 1) Renamed Run-psake to Invoke-psake 2) Timing report is always shown 3) All global variables replaced with script-level variables 4) All exported functions are advanced functions with comment help 5) Detailed errors are optionally logged to a file 6) Updated psake-builderTester.ps1 7) New exported $psake variable 8) The text "Build Succeeded!" is displayed at the end of a good build 9) Updated psake-buildTester.ps1 10) New tasksetup.ps1 examples/VerifyVariables.ps1 11) New example that verifies all psake variables 12) New "Assert" function 1) Renamed Run-psake to Invoke-psake 2) Timing report is always shown 3) All global variables replaced with script-level variables 4) All exported functions are advanced functions with comment help 5) Detailed errors are optionally logged to a file 6) Updated psake-builderTester.ps1 7) New exported $psake variable 8) The text "Build Succeeded!" is displayed at the end of a good build 9) Updated psake-buildTester.ps1 10) New tasksetup.ps1 examples/VerifyVariables.ps1 11) New example that verifies all psake variables 12) New "Assert" function Sep 10, 2009 issue 8 (XML output) commented on by matos.jorge - Not sure, just thought it might be a good idea to generate output as XML in case someone needed to act upon the raw output of the build. Not sure, just thought it might be a good idea to generate output as XML in case someone needed to act upon the raw output of the build. Aug 07, 2009 r37 (+ Added example for issue #14: missing dependency displays "...) committed by james.kovacs - + Added example for issue #14: missing dependency displays "circular reference" error. + Added example for issue #14: missing dependency displays "circular reference" error. Aug 07, 2009 issue 14 (Missing dependancies throw circular reference error) changed by james.kovacs - This is a bug. psake should provide a meaningful error message in this situation. Status: Accepted Owner: james.kovacs This is a bug. psake should provide a meaningful error message in this situation. Status: Accepted Owner: james.kovacs Aug 03, 2009 issue 14 (Missing dependancies throw circular reference error) reported by bigjimslade - Here is my script: task default -depends Test task Test -depends Compile, Clean { Write-Host "Running PSake" } I would expect it to error out with a message that the Compile and Clean are missing however here is the actual error message: Error: Circular reference found for task, I'm using psake v0.22 with powershell 1 Is this by design or a bug? Here is my script: task default -depends Test task Test -depends Compile, Clean { Write-Host "Running PSake" } I would expect it to error out with a message that the Compile and Clean are missing however here is the actual error message: Error: Circular reference found for task, I'm using psake v0.22 with powershell 1 Is this by design or a bug? May 13, 2009 issue 13 (Code review request) reported by matos.jorge - Purpose of code changes on this branch: Develop PowerShell V2 of psake that takes advantage of some of the new features like "Modules" and "Advanced Functions". I changed the style in my branch so that I could "think" better. We can change it back later if you like. I made some other changes too, like adding "TaskSetup" and "TaskTearDown" functions which are taken directly from NUnit. There are other changes too, please review and let me know what you think. We are going to need to support 2 versions of psake, for PSV1 and PSV2. Purpose of code changes on this branch: Develop PowerShell V2 of psake that takes advantage of some of the new features like "Modules" and "Advanced Functions". I changed the style in my branch so that I could "think" better. We can change it back later if you like. I made some other changes too, like adding "TaskSetup" and "TaskTearDown" functions which are taken directly from NUnit. There are other changes too, please review and let me know what you think. We are going to need to support 2 versions of psake, for PSV1 and PSV2. May 12, 2009 r36 (Added new features Removed Debug and added ShowFullError p...) committed by matos.jorge - Added new features Removed Debug and added ShowFullError parameter Added new examples Added new features Removed Debug and added ShowFullError parameter Added new examples May 11, 2009 issue 9 (Failed build still runs tests) commented on by peterseale - To kill two birds with one stone, I propose encasing all DOS commands inside some kind of Run-DosCmd function. This would take care of a) the halt-on-error problem, and b) cleanly separating command arguments from the program being run (I've had some awful troubleshooting experiences already with DOS commands.) A rough idea would be something like: Run-DosCommand ([string]$fullFilename, [string]$commandArgs, [switch]$haltonerror, [switch]$hideoutput, [switch]$whatif) If I get something workable out of my current script, I'll send along what I have. Currently this is just an idea in my head. ... In other news, PowerShell v2 is getting the concept of transactions; this may be what you're looking for Re: control flow when errors occur. http://blogs.msdn.com/powershell/archive/2008/05/09/powershell-transactions- quickstart.aspx To kill two birds with one stone, I propose encasing all DOS commands inside some kind of Run-DosCmd function. This would take care of a) the halt-on-error problem, and b) cleanly separating command arguments from the program being run (I've had some awful troubleshooting experiences already with DOS commands.) A rough idea would be something like: Run-DosCommand ([string]$fullFilename, [string]$commandArgs, [switch]$haltonerror, [switch]$hideoutput, [switch]$whatif) If I get something workable out of my current script, I'll send along what I have. Currently this is just an idea in my head. ... In other news, PowerShell v2 is getting the concept of transactions; this may be what you're looking for Re: control flow when errors occur. http://blogs.msdn.com/powershell/archive/2008/05/09/powershell-transactions- quickstart.aspx May 03, 2009 r35 (Created new version of psake that runs as a module and Run-P...) committed by matos.jorge - Created new version of psake that runs as a module and Run-Psake is now an advanced function. I also changed the psake-buildTester.ps1 to use the new Run-Psake function. Created new version of psake that runs as a module and Run-Psake is now an advanced function. I also changed the psake-buildTester.ps1 to use the new Run-Psake function. May 03, 2009 r34 (New branch created for psake that runs in PowerShell V2) committed by matos.jorge - New branch created for psake that runs in PowerShell V2 New branch created for psake that runs in PowerShell V2 Apr 19, 2009 issue 2 (Support for TeamCity) commented on by smbecker - I added a powershell script to allow for TeamCity integration. It contains scripts to support the TeamCity build service messages detailed here: http://www.jetbrains.net/confluence/display/TCD3/Build+Script+Interaction+with+TeamCity. We still need to figure out how we want to incorporate this into psake. I added a powershell script to allow for TeamCity integration. It contains scripts to support the TeamCity build service messages detailed here: http://www.jetbrains.net/confluence/display/TCD3/Build+Script+Interaction+with+TeamCity. We still need to figure out how we want to incorporate this into psake. Apr 19, 2009 issue 2 (Support for TeamCity) commented on by smbecker - I added a powershell script to allow for TeamCity integration. It contains scripts to support the TeamCity build service messages detailed <a href="http://www.jetbrains.net/confluence/display/TCD3/Build+Script+Interaction+with+TeamCity">here</a>. We still need to figure out how we want to incorporate this into psake. I added a powershell script to allow for TeamCity integration. It contains scripts to support the TeamCity build service messages detailed <a href="http://www.jetbrains.net/confluence/display/TCD3/Build+Script+Interaction+with+TeamCity">here</a>. We still need to figure out how we want to incorporate this into psake. Apr 19, 2009 r33 (Added powershell script to support TeamCity integration. Sti...) committed by smbecker - Added powershell script to support TeamCity integration. Still need to work out how this could be integrated into psake. Added powershell script to support TeamCity integration. Still need to work out how this could be integrated into psake. Apr 19, 2009 issue 10 (Create package script) commented on by smbecker - I added a psake script to test, increment version, and zip up psake releases. I still need to work out the details for uploading the zip file to Google Code. I added a psake script to test, increment version, and zip up psake releases. I still need to work out the details for uploading the zip file to Google Code. Apr 19, 2009 r32 (Added psake script to test (using psake-buildTester) and pac...) committed by smbecker - Added psake script to test (using psake-buildTester) and package psake releases. It also keeps the version in sync with Version.inc and increments the version accordingly. Added psake script to test (using psake-buildTester) and package psake releases. It also keeps the version in sync with Version.inc and increments the version accordingly. Apr 08, 2009 psake_v0.22.zip (psake v0.22) file uploaded by james.kovacs - Labels: Featured Type-Archive Labels: Featured Type-Archive Apr 08, 2009 r31 (Updated version to 0.23 after releasing 0.22.) committed by james.kovacs - Updated version to 0.23 after releasing 0.22. Updated version to 0.23 after releasing 0.22. Apr 08, 2009 r30 ([No log message]) committed by james.kovacs - [No log message] [No log message] Apr 08, 2009 r29 (Fixed minor indentation issue.) committed by james.kovacs - Fixed minor indentation issue. Fixed minor indentation issue. Apr 08, 2009 r28 (Corrected version number in script.) committed by james.kovacs - Corrected version number in script. Corrected version number in script. Mar 31, 2009 issue 9 (Failed build still runs tests) commented on by matos.jorge - I agree, until we can come up with a better recommendation. We should let developers know that they should always check the $lastExitCode or write functions for common console apps. We can remove the "exec" function and instead provide it as an example in the documentation. I agree, until we can come up with a better recommendation. We should let developers know that they should always check the $lastExitCode or write functions for common console apps. We can remove the "exec" function and instead provide it as an example in the documentation. Mar 31, 2009 issue 9 (Failed build still runs tests) commented on by james.kovacs - After thinking about it, we should probably recommend the approach that I suggested in Comment 8 above, except let psake users define these functions in their own includes. Less magic while maintaining the flow of the build script. If users don't like that, they can always check $lastExitCode themselves. So we just have to document this. After thinking about it, we should probably recommend the approach that I suggested in Comment 8 above, except let psake users define these functions in their own includes. Less magic while maintaining the flow of the build script. If users don't like that, they can always check $lastExitCode themselves. So we just have to document this. Mar 31, 2009 r27 (Updated version number to v0.22 to eliminate confusion with ...) committed by james.kovacs - Updated version number to v0.22 to eliminate confusion with the released v0.21. Updated version number to v0.22 to eliminate confusion with the released v0.21. Mar 30, 2009 r26 (Changed $global:includes to be Queue instead of Stack to ens...) committed by smbecker - Changed $global:includes to be Queue instead of Stack to ensure that included scripts are executed in order. Changed $global:includes to be Queue instead of Stack to ensure that included scripts are executed in order. Mar 28, 2009 issue 9 (Failed build still runs tests) commented on by james.kovacs - The problem that I see with checking $lastExitCode is it breaks up the flow of the script. It's like catching HResults in COM programming. You end up with really nasty arrowhead code and widely separated if/else clauses for error handling. Additionally you have to remember which executes are console (aka DOS) apps and which are PowerShell. The other major problem with my override approach is that we would have to override each command (msbuild, sn, etc.). Any new commands would not be caught. Maybe "exec" is the right approach... Have to think about it some more. The problem that I see with checking $lastExitCode is it breaks up the flow of the script. It's like catching HResults in COM programming. You end up with really nasty arrowhead code and widely separated if/else clauses for error handling. Additionally you have to remember which executes are console (aka DOS) apps and which are PowerShell. The other major problem with my override approach is that we would have to override each command (msbuild, sn, etc.). Any new commands would not be caught. Maybe "exec" is the right approach... Have to think about it some more. Mar 26, 2009 r25 ([No log message]) committed by matos.jorge - [No log message] [No log message] Mar 26, 2009 r24 ([No log message]) committed by matos.jorge - [No log message] [No log message] Mar 26, 2009 r23 ([No log message]) committed by matos.jorge - [No log message] [No log message] Mar 26, 2009 r22 (refactoring code) committed by matos.jorge - refactoring code refactoring code Mar 26, 2009 r21 (refactoring code) committed by matos.jorge - refactoring code refactoring code Mar 26, 2009 r20 (refactoring code) committed by matos.jorge - refactoring code refactoring code Mar 26, 2009 r19 (First pass at a simple psake build tester. It runs each exa...) committed by matos.jorge - First pass at a simple psake build tester. It runs each example build script and reports if the build passed or failed. First pass at a simple psake build tester. It runs each example build script and reports if the build passed or failed. Mar 25, 2009 issue 12 (V2 Branch) reported by matos.jorge - Create a branch for PowerShell V2. Use new features such as: 1) Try/Catch 2) Module 3) Steppable Pipeline 4) Script Command-lets 5) Data Language 6) etc... We'll have to determine how to maintain both versions for a while but I think that's Create a branch for PowerShell V2. Use new features such as: 1) Try/Catch 2) Module 3) Steppable Pipeline 4) Script Command-lets 5) Data Language 6) etc... We'll have to determine how to maintain both versions for a while but I think that's Mar 24, 2009 issue 11 (Build Variables) commented on by james.kovacs - Good point, though the point was to make the variables available to build scripts. We might want to revisit whether $debug should be renamed or is even necessary. Good point, though the point was to make the variables available to build scripts. We might want to revisit whether $debug should be renamed or is even necessary. Mar 24, 2009 issue 11 (Build Variables) commented on by smbecker - Do we need $psake-debug? Doesn't the $debug switch variable already exist in scope? Do we need $psake-debug? Doesn't the $debug switch variable already exist in scope? Mar 24, 2009 issue 8 (XML output) commented on by smbecker - How do you envision this working for external processes called from psake scripts? Would it just wrap the string output in a CDATA section? How do you envision this working for external processes called from psake scripts? Would it just wrap the string output in a CDATA section? Mar 23, 2009 r18 (example of a precondition) committed by matos.jorge - example of a precondition example of a precondition Mar 23, 2009 r17 (Changed all error messages to use "Error" prefix Changed Con...) committed by matos.jorge - Changed all error messages to use "Error" prefix Changed ContinueOnError code to emit dashes "-" around error messages Changed all error messages to use "Error" prefix Changed ContinueOnError code to emit dashes "-" around error messages Mar 22, 2009 r16 (Changed the "Timing" code to use Format-Table. This is bett...) committed by matos.jorge - Changed the "Timing" code to use Format-Table. This is better than hard-coding the size. Changed the "Timing" code to use Format-Table. This is better than hard-coding the size. Mar 21, 2009 issue 9 (Failed build still runs tests) commented on by matos.jorge - You're right, it's a crazy idea :) Maybe we should get rid of the "exec" function and stick with having the developer be aware that he needs to check the $lastExitCode and throw an exception for any DOS executables that he runs? Any PS Command-Lets that fail are caught now by setting the $errorActionPreference variable so we do catch more errors than before. Is it really that bad to have to check the $lastExitCode? Thoughts? You're right, it's a crazy idea :) Maybe we should get rid of the "exec" function and stick with having the developer be aware that he needs to check the $lastExitCode and throw an exception for any DOS executables that he runs? Any PS Command-Lets that fail are caught now by setting the $errorActionPreference variable so we do catch more errors than before. Is it really that bad to have to check the $lastExitCode? Thoughts? Mar 20, 2009 issue 9 (Failed build still runs tests) commented on by james.kovacs - I agree. I would rather the developer not have to remember anything - either "exec" prepended or "\| fail" appended to each command. It would be even better if it was general so that we didn't have to code per-command (e.g. msbuild.exe, sn.exe, etc.). One crazy idea, which is unfortunately is command-specific is... function msbuild([string[]]$msbuildArgs) { & $frameworkDir\msbuild.exe $msbuildArgs if($lastExitCode -ne 0) { throw "Failed to execute msbuild with parameters ""$msbuildArgs""" } } N.B. I moved $frameworkDir from local to script scope. Besides having to code one for each command (msbuild, sn, etc.), this would only work is the file extension isn't specified (i.e. msbuild would work, but msbuild.exe wouldn't). Overall I like this option since it allows us to use the same syntax in psake as one would use on the command line. Thoughts? I agree. I would rather the developer not have to remember anything - either "exec" prepended or "\| fail" appended to each command. It would be even better if it was general so that we didn't have to code per-command (e.g. msbuild.exe, sn.exe, etc.). One crazy idea, which is unfortunately is command-specific is... function msbuild([string[]]$msbuildArgs) { & $frameworkDir\msbuild.exe $msbuildArgs if($lastExitCode -ne 0) { throw "Failed to execute msbuild with parameters ""$msbuildArgs""" } } N.B. I moved $frameworkDir from local to script scope. Besides having to code one for each command (msbuild, sn, etc.), this would only work is the file extension isn't specified (i.e. msbuild would work, but msbuild.exe wouldn't). Overall I like this option since it allows us to use the same syntax in psake as one would use on the command line. Thoughts? Mar 20, 2009 r15 (Updated include processing to allow for nested include state...) committed by smbecker - Updated include processing to allow for nested include statements. Updated include processing to allow for nested include statements. Mar 20, 2009 r14 (Moved $docs check to after includes are processed to pick up...) committed by smbecker - Moved $docs check to after includes are processed to pick up any tasks that are in included scripts. Moved $docs check to after includes are processed to pick up any tasks that are in included scripts.

issue 9 (Failed build still runs tests) commented on by james.kovacs - I agree. I would rather the developer not have to remember anything - either "exec" prepended or "| fail" appended to each command. It would be even better if it was general so that we didn't have to code per-command (e.g. msbuild.exe, sn.exe, etc.). One crazy idea, which is unfortunately is command-specific is... function msbuild([string[]]$msbuildArgs) { & $frameworkDir\msbuild.exe $msbuildArgs if($lastExitCode -ne 0) { throw "Failed to execute msbuild with parameters ""$msbuildArgs""" } } N.B. I moved $frameworkDir from local to script scope. Besides having to code one for each command (msbuild, sn, etc.), this would only work is the file extension isn't specified (i.e. msbuild would work, but msbuild.exe wouldn't). Overall I like this option since it allows us to use the same syntax in psake as one would use on the command line. Thoughts?

I agree. I would rather the developer not have to remember anything - either "exec" prepended or "| fail" appended to each command. It would be even better if it was general so that we didn't have to code per-command (e.g. msbuild.exe, sn.exe, etc.). One crazy idea, which is unfortunately is command-specific is... function msbuild([string[]]$msbuildArgs) { & $frameworkDir\msbuild.exe $msbuildArgs if($lastExitCode -ne 0) { throw "Failed to execute msbuild with parameters ""$msbuildArgs""" } } N.B. I moved $frameworkDir from local to script scope. Besides having to code one for each command (msbuild, sn, etc.), this would only work is the file extension isn't specified (i.e. msbuild would work, but msbuild.exe wouldn't). Overall I like this option since it allows us to use the same syntax in psake as one would use on the command line. Thoughts?

Older