set variable for parent project in chain
Hi, I did a search through the topics and the documentation and couldn't find answers to these questions.
I have project A pass chaining to project B in a build step. Is it possible for project B to set a variable that project A will see when project B's job completes? Also, if project A chained project B with pass wait, while project B is running, is it able to override the result that is passed to project A? In other words, if project B fails (I still want it to fail), is it still possible to send project A a "pass"? I basically have a step in project B that should fail project B, but I don't want it to fail the calling project. Thanks for your help. |
6 answers
|
Maybe I can simplify the questions above into a more basic question:
Is there a way through the Build Forge environment to send a "message" back up the chain to the chain caller? Or do I have to resort to writing a file somewhere and then reading it when the chain returns? If the above is possible, then I can script/Ant my way through getting the effect I want. |
I have project A pass chaining to project B in a build step. Is it possible for project B to set a variable that project A will see when project B's job completes? The .set command should do what you want. It updates the variable in the master environment. Note, however, that you will have to explicitly name the environment for the step you want to use the modified value in, otherwise the step will use a cached copy of the environment, containing the old value. In my test, I have an environment variable called FRUIT which is initially set to "apples" Project A uses environment "testenv" and has 3 steps: step 1 > echo $FRUIT step 2 > .sleep 2 step 3 (explicitly uses environment "testenv") > echo $FRUIT the pass chain for step 1 calls (and waits for) project B, which has one step: step 1 > .set env testenv FRUIT=bananas NOTE: the .sleep seemed to be necessary on my installation to make this work reliably. |
I have project A pass chaining to project B in a build step. Is it possible for project B to set a variable that project A will see when project B's job completes? The .set command should do what you want. It updates the variable in the master environment. Note, however, that you will have to explicitly name the environment for the step you want to use the modified value in, otherwise the step will use a cached copy of the environment, containing the old value. In my test, I have an environment variable called FRUIT which is initially set to "apples" Project A uses environment "testenv" and has 3 steps: step 1 > echo $FRUIT step 2 > .sleep 2 step 3 (explicitly uses environment "testenv") > echo $FRUIT the pass chain for step 1 calls (and waits for) project B, which has one step: step 1 > .set env testenv FRUIT=bananas NOTE: the .sleep seemed to be necessary on my installation to make this work reliably. Hi, I was going to suggest what Paul has already detailed. Another option which I think you alluded to is to write to a file in the chained project, and then in the calling project to do something like the following: .bset env "TEST_VAR=`cat var_value.txt`" bju |
|
H,
For your second question, I'm curious if setting the step's 'On Fail' parameter to 'Continue On Fail' is not something that you want to do because that would allow the calling project to continue on. However, the ultimate build status would report fail warn instead of pass. bju |
|
Thanks for all of the advice. I am starting to get somewhere and will post when I have a solution.
Unfortunately I hit another dilemma. I rely on BF_CALLER_* (in particular BF_CALLER_PROJECTNAME) to know who the previous person is in the chain. This however doesn't seem to work. If I have Project A chains Project B chains Project C: - Project B correctly reports Project A in BF_CALLER_PROJECTNAME - Project C incorrectly (in my opinion) reports Project A in BF_CALLER_PROJECTNAME What you find when looking at the logs in Project C is BF_CALLER_PROJECTNAME is correctly set to Project B, but a few lines later gets clobbered by what looks like Project B's environment, that resets the value to Project A. :( Is this the expected behavior? What is the point of meta-data for chaining when it gets overwritten 2 levels deep. I am running on what I believe to be the latest released version of BF. |
Hi, I did a search through the topics and the documentation and couldn't find answers to these questions. In the version you are running, it appears that setting the "Stack BuildForge Env Variables" parameter to 'Yes' (in Adminstration->System) will get to what you're looking for (at C's scope, Project A's name will be in BF_CALLER_CALLER_PROJECTNAME and B's name will be in BF_CALLER_PROJECTNAME). |
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.