I have a few libraries that needs to be tested under multiple versions of python. I have defined each library as a plan. For each plan I have two stages:

  • Setup (Source Code Checkout + "make install")
  • Run Tests

Each Run Tests stage has multiple jobs, currently

  • Test Python 2.7
  • Test Python 3

Each of these jobs consists of two tasks, for example:

  • Make test2.7 (creates nosetests.py27.xml)
  • JUnit task to read nosetests output

What I expect to happen is:

The Setup stage should run once, only when it is finished, the Run Tests stage commence. The Run Tests jobs should be able to take advantage of the environment set up in the Setup stage, and the shell will be in the same working directory.

Each job in the Run Tests stage will run in parallel, and their individual test output should be aggregated for the complete plan results.

This seems to be supported by the description given on the plan's configuration Stages tab:

"Each stage within a plan represents a step within your build process. A stage may contain one or more jobs which Bamboo can execute in parallel. For example, you might have a stage for compilation jobs, followed by one or more stages for various testing jobs, followed by a stage for deployment jobs."

What happens actually is:

Each of the jobs in the Run Tests stage fails as if the Setup stage never happened or the state of the shell is not what I expect. The error shown is: "make: *** No rule to make targettest2.7'. Stop."`

After adding some @echo "$(shell pwd)" lines to my Makefile, I notice that the stages are in fact not running in the same build_dir -- Setup runs in $(PROJECT)-$(PLAN)-JOB1 and the first job in Run Tests runs in $(PROJECT)-$(PLAN)-PY27

Is there a way to configure the stages to run in the same build_dir? Or is there another way to configure multiple test runs within my plan that I should use?

1 Answer 1


Artifacts is the answer. That, and a bit of restructuring of my Bamboo Stages.

This being a Python project, the files required to build it are only:

  • Makefile
  • setup.py
  • setup.cfg
  • requirements.txt
  • The source directory

In the Setup job's configuration, I created a shared artifact for each of those (using tar to roll up the source dir).

I removed the make install task from the Setup stage, so that stage's only tasks are the Source Code Checkout one and a new target make tarball.

In each of the test runner jobs, I added shared artifact dependencies for each of the artifacts that were just created, and added a make untar and a version specific build task (make install2.7, etc..)

  • Good answer , artefacts are a the right way to do it , this then allows your jobs to scale to multiple build nodes without extra effort. If you used a local path solution then it would need to be restricted to a specific node.
    – Amias
    Commented Jan 11, 2018 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.