Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bin folder to PATH #281

Merged
merged 1 commit into from
May 4, 2015
Merged

Add bin folder to PATH #281

merged 1 commit into from
May 4, 2015

Conversation

JCapriotti
Copy link
Contributor

Adds \bin folder to PATH for easier install and calling Pester.

Adds \bin folder to PATH for easier install and calling Pester.
@dlwyatt
Copy link
Member

dlwyatt commented Feb 17, 2015

I'm not sure why people keep latching on to bin\pester.bat. We don't really support or test that file; it was just part of our CI job (and we're not even using all of it anymore.) ChocolateyInstall.ps1 already adds Pester to the PSModulePath, which should be sufficient.

I don't mind leaving Pester.bat in our distribution as an example (or even a file people can use as-is if they choose) of how to execute Pester tests from outside of PowerShell, but I also don't want to commit us to maintaining or supporting that script. By adding it to the path as part of our installation script, that's sort of implicitly saying that we do support it.

@JCapriotti
Copy link
Contributor Author

I was using it because of the "Running Tests" section in README.md. I can update that to say PS> Invoke-Pester if that is preferred.

@dlwyatt
Copy link
Member

dlwyatt commented Feb 17, 2015

Wow, that sucks... :\

@nohwnd , opinions on this? Looks like we've been telling people to use pester.bat all along. We can either remove those references from our documentation, or start testing / supporting the batch file.

In our recent updates to the CI job, we had problems where failed tests weren't aborting the build for some reason (because the exit code from pester.bat appeared to be 0 when it should not have been.) I just updated the CI job to use PowerShell runners and directly execute Invoke-Pester with -PassThru to work around that, but if we do need to support pester.bat, we might have some troubleshooting to do.

@JCapriotti
Copy link
Contributor Author

FWIW as a newcomer to Pester, I only started using pester.bat because it was in the readme. I liked the simplicity of it, but only because I didn't know about Invoke-Pester... I'm planning to use that moving forward.

@nohwnd
Copy link
Member

nohwnd commented Feb 17, 2015

@dlwyatt Personally I use the .bat file sometimes to run all Pester tests in clean session of PowerShell. I don’t use it for any other purpose. If it has issues then I’d suggest to drop it in the next major release.

@mwrock
Copy link
Member

mwrock commented Feb 17, 2015

I do think there is some value in supporting a .bat file. Fortunately TeamCity does have a powershell runner but most other build systems dont and expect to invoke builds from the native shell (sadly cmd.exe) an get exit codes back to determine success or failure. This tends to be more complicated to get right then one would expect. Providing a .bat that can deal with this correctly and pass good defaults to Invoke-Pester that one would use in a build server scenario can be a nice feature.

@dlwyatt
Copy link
Member

dlwyatt commented Feb 17, 2015

I've modified the readme.md file for now. It still mentions pester.bat, but only as an example of how you can integrate with CI servers that don't support running Invoke-Pester directly.

@dlwyatt
Copy link
Member

dlwyatt commented Mar 15, 2015

Hmm, I haven't been able to reproduce the problem in TeamCity. Just set up some build configurations that used pester.bat instead of a powershell runner, and it appears to be aborting the build properly when there are failed tests.

I definitely saw TC try to move on and publish the module when there were failed tests back when I was tinkering with the build configs, but that may have been something I configured wrong in TeamCity rather than a problem with the batch file itself.

@dlwyatt
Copy link
Member

dlwyatt commented Mar 20, 2015

I think I'll just merge this shortly. However, if we're going to start supporting the batch file (and since we're not actually using it anymore in our own build), we should take these hard-coded parameters out of it: -OutputXml Test.xml -Strict

The -EnableExit switch will still be hard-coded because the batch file uses that to determine its own exit code, but any other Pester parameters would just be passed in by the callers of the batch file.

dlwyatt added a commit that referenced this pull request May 4, 2015
@dlwyatt dlwyatt merged commit 0e876e5 into pester:master May 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants