It's all about the answers!

Ask a question

Do conditional steps in Build Forge actually work?


Daniel martin (10122926) | asked Nov 07 '13, 7:55 a.m.
 I have a conditional step that depends on a varaiable ${PRIMARY_DIR}. The step condition is:
hastext ${PRIMARY_DIR}, have also tried hastext (PRIMARY_DIR), hastext (${PRIMARY_DIR}). When the step runs i get the following: 
The condition on the step [hastext https://gbl00458.systems.uk.hsbc:9103/jazz/] evaluated false, step will not be executed.

How is that evaluating to false?

4 answers



permanent link
Ryan Ruscett (1.0k413) | answered Nov 07 '13, 9:35 a.m.
 Hey Daniel, 
They do work yes. Here are two examples. One using a .bset. The other using a variable created in under environment. 

Example 1
Step 1
.bset env "test=texttext"

Step 2 
Condition
hastext(${test}) is true it will echo it worked. If it was false it would echo failure.

Results:
Echo it worked
	
Example 2
	
Created two environment variables. TEST and TESTING. TEST has no value while TESTING has texttext
	
Step 1
	
hastext(${TESTING})
	
RESULT:
	
Echo it Worked
	
Step 2
	
hastext(${TEST})
	
RESULT:
	
Echo Failure
	

How are you trying to set the variable? Via .bset or from a variable created within BF. Also, what is the version of Build Forge you are using? .bset has limitations or best practices in the way it should and should not be used. Here is a link on that below. Any additional details you can offer up would be great too. Thanks!
	
http://pic.dhe.ibm.com/infocenter/bldforge/v7r1m3/index.jsp?topic=%2Fcom.ibm.rational.buildforge.doc%2Ftopics%2Fdotcmd_bset.html
	


Comments
Daniel martin commented Nov 07 '13, 9:53 a.m.

 The variable in question is part of the BF project env.  I am trying to determine if that variable has content (hastext).  When it evaluates:  hastext (${PRIMARY_DIR}) it is showing as false: 

The condition on the step [hastext https://gbl00458.systems.uk.hsbc:9103/jazz/] evaluated false, step will not be executed.
Clearly PRIMARY_DIR has text, so why is it evaluating to false.  My goal is to run one of 2 command based on whether or not PRIMARY_DIR has content.


permanent link
Ryan Ruscett (1.0k413) | answered Nov 07 '13, 11:07 a.m.
 If the PRIMARY_DIR is an environment set variable. Which would mean that every time the project runs. It sets this variable. The only way to set it to nothing would be to use a .bset, which using a .bset to set an environment variable to nothing wont work. The idea to check whether the variable has content would not be needed, because it will always have content if it's an environment variable. 

I think there is still something I am missing here. Is this a changed project, inline library or contained within a threaded step? Also, what version of Build Forge is this?

Comments
Daniel martin commented Nov 07 '13, 11:25 a.m.

 I have two BF projects (A and B).  One project (A) has a variable PRIMARY_DIR, the other project (B) has variable bfbuild_xml_location.  I now need to chain a project from A and B.  Inside this project I need to know which variable has value, so I can run the correct command.  I set a step to be conditional, as referenced above.  If I am running project "A" the condition should evaluate to true, but as you can tell it is evaluating to false.  If I launch project "B" it will evaluate to false, but I really don't think it is evaluating it properly because of project A  response.


Daniel martin commented Nov 07 '13, 11:37 a.m.

 As an example here is a run from project B

COND    The condition on the step [hastext(PRIMARY_DIR)] evaluated true, this step will continue to be executed.
EXEC    Locale set to 'C'
PTY allocated pseudo-tty pipe
This should evaluate to false as PRIMARY_DIR doesn't exist in Project B


Daniel martin commented Nov 07 '13, 11:50 a.m.

 We are running 7.1.3.3


permanent link
Ryan Ruscett (1.0k413) | answered Nov 07 '13, 12:45 p.m.
According to BF PRIMARY_DIR does exist in project B. How are you calling the project in the condition step. Are you using a .run or .runwait? A .run <projectB> Will actually inherit the calling projects (projectA) environment and variables and continue running. Basically it will hand off all variables to project B to run. BUT if you set a variable after calling the project B. It wont get the additional Variables.

You have two projects. A and B . A has PRIMARY_DIR that is an environment variable. So this will always evaluate to true. How could this not be true? If project B is called from A, then B also has a PRIMARY_DIR. It was inherited. The only time I would use hastext would be if I was doing a grep or scanning a file with awk searching for  a specific value. If I found that value I would do a .bset and assign it a variable. If it wasn't there i would not set anything. Then i can do a condition step with hastext to determine if the variable was set or not. How are you setting the variables, if they are BF environment variables that have a value. They will always be true. If Project B isn't suppose to have a PRIMARY_DIR then why would it have a hastext for PRIMARY_DIR?

How are you calling these projects? Is it with .run?

permanent link
Daniel martin (10122926) | answered Nov 07 '13, 1:01 p.m.
 i have found a solution
1) setup variables (PRIMARY, location during the build that should contain the values for PRIMARY_DIR and bfbuild_xml_location.
2) use the "contains" test to determine if either PRIMARY/location have the variable they were meant to be instantiated with: contains(${location},bfbuild) for example.  If "location" contains "bfbuild", then I know I need to use the command for a project that has PRIMARY_DIR.

Comments
Ryan Ruscett commented Nov 07 '13, 1:55 p.m.

Excellent, that would work too. I guess I was just confused how the variables could not have the intended value when set as a BF Environment variable. Since that would mean it would have the same value every time, unless .bset was used which i don't know if it was or not.

Your answer


Register or to post 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.