Referring to Windows variables
We run builds on a Windows machine. There's a similar problem for
UNIX-like systems, I presume. I want to refer to a Windows variable in a step's statement. I currently have if %%errorlevel%% neq 0 (echo error in checkstyle run for app& exit /b 1) This works only by coincidence, so to speak. BuildForge sees %errorlevel%, and because it happens not to be a BuildForge property, it emits SET Reference to undefined variable: errorlevel but substitutes "errorlevel" for it. The statement is then presented to Windows as if %errorlevel% neq 0 (echo error in checkstyle run for app& exit /b 1) which does what I want. I really dislike referring to undefined / undeclared variables: ever since FORTRAN IV I've thought it sucked, and I wish it were a fatal error. Is there some other way to escape the % characters so that Windows sees it but that Build Forge does not? It just occurred to me that I could define a Build Forge property named errorlevel with the value errorlevel, and so on for every Windows variable that I want to refer to, but that seems a little kludgy if there's a Build Forge way. -- Tim McDaniel, tmcd@panix.com |
5 answers
|
In article <humajb>,
bju <ulbricht> wrote: Tim McDanielwrote: Thank you. Just to make sure: that works because Build Forge puts all its properties into the Windows/UNIXy environment? I suspect that, if there aren't any drawbacks, it would be the default or just invarible. The only problem I could see is if the Windows environment can't store a Build Forge environment variable -- like - if a Build Forge environment variable name can have characters that Windows doesn't allow - if Build Forge environment variable names are case-sensitive but Windows's are not -- Tim McDaniel, tmcd@panix.com |
We run builds on a Windows machine. There's a similar problem for Hi Tim, There is a Build Forge trigger environment variable named _NO_PREPARSE_COMMAND . If you set that variable in your environment for the step to any value, the system will not parse and resolve variable values before sending commands to the agent. bju |
In article <humajb>, Tim McDanielwrote: Thank you. Just to make sure: that works because Build Forge puts all its properties into the Windows/UNIXy environment? I suspect that, if there aren't any drawbacks, it would be the default or just invarible. The only problem I could see is if the Windows environment can't store a Build Forge environment variable -- like - if a Build Forge environment variable name can have characters that Windows doesn't allow - if Build Forge environment variable names are case-sensitive but Windows's are not -- Tim McDaniel, tmcd@panix.com Hi Tim, The documentation lists this information about variable names, which hopefully prevents naming problems.
One of the other things to watch out for is that your steps are less cross platform now because of the use of %VAR_NAME% or $VAR_NAME to expand variables. bju |
|
In article <hulr88>,
Tim McDaniel <tmcd> wrote: We run builds on a Windows machine. There's a similar problem for I tried that. What I forgot is that Build Forge puts all its variables into the environment. That means that it created a CMD environment variable named ERRORLEVEL with value ERRORLEVEL. Which (I believe) turned off the special meaning of ERRORLEVEL: that is, CMD no longer set it to be an integer representing the exit code of the last command. Which screwed up BAT files in so many weird ways it wasn't funny. And ant on Windows is actually ant.bat, so it started to report BUILD SUCCESSFUL but an ant run calling it saw it as failed. Really freakin' mysterious. So: SEVERE TIRE DAMAGE MAY RESULT if you change builtin Windows or Unix variables in a Build Forge environment. I think you could, for example, define a Build Forge variable JOE_BLOGGS to be ERRORLEVEL, and then use %%JOE_BLOGGS%% to get %ERRORLEVEL%. But I'd still like a way that's less kludgy than defining a trampoline variable like that or turning off all Build Forge variable expansion in the step. -- Tim McDaniel, tmcd@panix.com |
|
Just an FYI.
For this particular application, checking for ERRORLEVEL NEQ 0 in Windows but not causing a Build Forge "undefined variable" warning, I now realize I can do if errorlevel 1 (some actions) if not errorlevel 0 (the same actions) But I plan to avoid the entire problem of variable reference by calling a CMD file. -- Tim McDaniel, tmcd@panix.com |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.