Windows PowerShell이 나와서 반갑다는 이야기를 쓴지가 5분이 되지 않았는데, 아래와 같은 슬픈 현실이...
When PowerShell is called, a separate shell is created. Rational Build Forge is unable to access this shell and never receives a response from the agent's PowerShell process/shell. The step eventually times out in Rational Build Forge and the build fails.
PowerShell을 호출하면, 다른 쉘(즉 다른 프로세스)이 시작되기 때문에, Build Forge agent로서는 Return 코드를 받거나, 로그 스트림을 받아낼 수가 없다는 이야기다. 결국, 맨 처음 호출된 PowerShell 프로세스로 부터는 아무런 응답을 받지 못하고, TMO가 발생한다는 이야기다.
BF의 잘못인가? 아님 PowerShell 아키텍처가 잘못 된 것인가.
내가 보기에는 Windows 아키텍처 상 PowerShell에서 단일 프로세스로 스크립팅을 처리할 수 없기 때문이 아닐까 싶다.
윈도우의 기본 명령어 인터프리터(일명, CMD)에서 PowerShell script를 처리하지 못하고, PowerShell 인터프리터 프로세스를 새로 띄움으로서 발생하는 치명적인 약점인 것이다.
BF의 다음버전에서는 이를 반영할 수 있을까? MS가 수정할 것 같지도, 수정할 수 있을 것 같지도 않으니 말이다.
그나마, 링크된 문서에 따르면 workaround로 VB script로 PowerShell을 둘러싸는 방법을 쓸 수는 있단다. 쯧쯧, 이 어찌나 처절한 방법인가.
Resolving the problem Because PowerShell opens its own shell, Rational Build Forge cannot directly interact with PowerShell. Future versions of Rational Build Forge may adopt an architectural change that allows interaction with PowerShell, but currently the only method of facilitating this interaction is to wrap the PowerShell command within a Microsoft Visual Basic script. Some users have had success using the site at the following link:
http://blog.sapien.com/index.php/2006/12/20/schedule-hidden-powershell-tasks
이 글은 스프링노트에서 작성되었습니다.
