batadjanov848667898, thank you for feedback.

Resolution is marked as Answered and answer is now added to issue description.

I feel like the status of Resolved is not an appropriate one for this task. It gives you the false positive as it did to me that this enhancement is implemented. I'd expect a status of 'Won't do' or similar one

Modifying global and plan variables will not be implemented due to concurrency issues that would be created.

However, since Bamboo 5.7 you can use Inject Variables task to add variables to "result" scope and use them later on, in subsequent Task, Stages and to create deployment release.

I would really like to programmatically link the version of our software to the deployment package by reading this number from the AssemblyInfo file and then appending the build number to the end. If the capability to write to a variable existed, then I would be able to append both these variables together to achieve this end.

Hi there,

Fundamentally we cannot allow plans to change Plan or Global variables at runtime as it is possible to have other plans running concurrently at the same time.

If you need to pass variables between Stages, you can use the Variable Inject Plugin and pass the variables around via Artifact Sharing in a text file.

As Anton said earlier, it would be great to get a better description of your use-case.

Thanks
James Dumay
Product Manager

Hi Larry,

Do you need to exchange data between Tasks in a given Job, or between Jobs?

The best way to exchange data between Jobs is artifact passing:
http://confluence.atlassian.com/display/BAMBOO/Configuring+Artifact+Sharing+between+Jobs

Tasks in a single job run sequentially to each other and in 99.9% of the cases, in the same working ditrectory to each other.

Due to tasks running sequentially there should not be any problems with parallel execution.

As tasks share the same working directory you could get them to exchange information using a file somewhere on disk.

I feel that I am missing something about what you are trying to achieve.

Please let me know why the above will not work for you?

Cheers,
Anton

While setting one or two values would be moderately useful, my need is to retain a collection of application and environment data generated during Task execution and used by future Tasks. Eg. I generate a security key in Task 8 and then need to use that key in all future Tasks. In the current Bamboo system I need to manage my own information store, unique to each run, outside of Bamboo.

So, how would I do this? First, the goal is to allow Bamboo to collect and manage Run specific information generated during the execution of a Bamboo Plan. This information could be retained at the end of a Run and used by the customer to record history of arbitrary information.

To achieve this you need a generic interface that allows the processes initiated by Tasks to change multiple arbitrary application specific variables. Also that these variables would accumulate through the execution of the Project Execution Run.

Interface: XML via STDOUT (for example)

Write a Task plugin that expects an XML document from the action it runs. The XML could be scanned for known Global/Project variables - those variables would be set accordingly. The rest of the document would be merged into a Run specific variable called APP_RUN_XML or similar. This XML doc would accumulate the output of all Tasks during the execution of a run.

When a new Task starts, it receives the current APP_RUN_XML as input (STDIN?). Ideally the Global & Project variables would be included in this XML. The user's code can do what it likes with this data. And again, on exit the user's app would send back an XML doc.

Finally, at the end of a run, the accumulated wisdom in APP_RUN_XML would be saved as part of the Run data.

Issues: Parallel execution? An agent finishing up a Task would have to lock APP_RUN_XML during the update.