NOTE: I am not sure how to break down DOCKER_CONATAINER_IDS into individual ids when used in wait for ports field. At the moment I only create one container so problem yet.
should be fixed now. However, it seems to me, that you use $DOCKER_CONTAINER_IDS in little different way than it was intended. It can be expanded in Container ID(s) field, however, it was intended rather to provide real container ID in this field and once the container is started, it will create $DOCKER_CONTAINER_IDS env. variable which is intended to be used in other build steps.
vjuranek added a comment - 2014-08-04 18:58 Hi, should be fixed now. However, it seems to me, that you use $DOCKER_CONTAINER_IDS in little different way than it was intended. It can be expanded in Container ID(s) field, however, it was intended rather to provide real container ID in this field and once the container is started, it will create $DOCKER_CONTAINER_IDS env. variable which is intended to be used in other build steps.
We are trying to configure a build-chain in which every job is a step towards production.
We would like to start the sanity_check with the resulting (tagged) image from the init_ws job, then use the resulting image for build step, and reuse the build result for unit and coverage steps. Then use the clean build step to create a package.
If only we could pass the current jobs image tag to the next job which in turn will run that container as starting point.