We have several environment variables that are set for each version of our build. Because of this, we have scripts that run which update the variables, and then future scripts use these variables as part of the build.
How can I make the variables that are set from Script A persistent so that they are accessible by Script B? I can see in the log something along the lines of:
But, when Script B is executed, I get the following error:
-----------------
I just tried setting the COMPFILE variable in my global variables for Bamboo, and I STILL get this error:
26-Feb-2014 12:42:54C:\Users\ctote\bamboo-home\xml-data\build-dir\MOM-CPP-JOB1>ratlperl make.pl -ACTION=DEPEND
26-Feb-2014 12:42:54environment variable MOM_COMPFILE not set! (check setenv.cmd)
26-Feb-2014 12:42:54Aborting script make.pl!
I'm starting to wonder if Bamboo is the right product for our company. Any help is appreciated.
You can try the Bamboo Inject Variables Plugin. This allows you to manage variables in your plan:
https://marketplace.atlassian.com/plugins/com.atlassian.bamboo.plugins.bamboo-variable-inject-plugin
Your other option would be to dump variables to a simple db and read them back.
For every bamboo task, yes, but not if they are in the same script task.
A script is written out to a temporary .bat and run (.ps1 for Powershell option)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not entirely sure this will solve our problem. We want access to the variables we set during the task that runs this perl script. The plugin looks like it just makes some things available throughout Bamboo, but not necissarily in the scripts you run?
If I do:
call setenv.cmd
ratlperl make.pl
It's like my make.pl has no clue what was set during setenv.cmd... Does bamboo launch a new shell for every task? That seems a bit absured, but I guess it's possible?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hm, ok then I'm somewhat confused as to why my variables aren't being recognized. Or also, if they are recognized during make.pl , they show paths as ${bamboo.mypath}/comps.dat
If I set my variables during the same task, such as:
Global Variable:
workspace : ${bamboo.capability.build-dir}\${bamboo.buildKey}
My Inline Script:
:: where the c++ code resides
set CODE_PATH=${bamboo.workspace}
Then, when I kick off a perl script in the same task I get:
make.pl Could not open data file : '${bamboo.capability.build-dir}/${bamboo.buildKey}/comps.dat' – Aborting script!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Where is that Global variable? Bamboo doesn't support nested variables natively.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You'll need the Nested Variables for Bamboo plugin if you want nested variables.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This isn't really an option for us - since we don't want to be permanently setting the variables every time we do a build. Is there really no alternative here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Environment variables set in a script or command line only exist for that session, it doesn't directly relate to Bamboo or any CI tool. To set an environment variable permanently, you'll have to use setx or modify the registry and broadcast it yourself.
setx has a slightly different format
setx COMPFILE comps.dat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This isn't really an option for us - since we don't want to be permanently setting the variables every time we do a build. Is there really no alternative here? I mean, I have the .cmd file in the same script task as the call to our make.pl file - is Bamboo really executing those in two separate command shells?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.