By default, non-master branches are not deployed on the Docker Hub. With
this patch, you can enable this feature by setting the environment
variable DEPLOY_BRANCH in the circle configuration.
It will not be tagged with the "latest" tag but instead derive the tag
from the branch name. Since "/" are not allowed in Docker tag names, all
"/" are replaced by "-".
When testing code in Scope, I use circle to build the Docker image but I
don't want to always use my "master" branch for development.
With this patch, CircleCI will push by default to the Docker repository
$DOCKER_ORGANIZATION/scope. If $DOCKER_ORGANIZATION is not defined, it
will use $DOCKER_USER/scope.
I would to do some changes in Scope and test my changes in Kubernetes,
following the guide on:
https://github.com/weaveworks/scope#using-weave-scope-with-kubernetes
For that, I need a Docker image of Scope hosted on a Docker hub and
reference that Docker image in my Kubernetes resource yaml file. Instead
of building Scope on my laptop and pushing it manually on my Docker Hub
account, I am using my CircleCI account to do this automatically.
This patch fixes the deployment target in circle.yml. It uses the
environment variable $DOCKER_USER from the CircleCI settings to guard
against unintended deployment. As before, only the "master" branch will
trigger the deployment.
This change should not impact the build of the official Scope Docker
image.
Another call to gce.sh was added in commit abebb0f197 ("Build new test VM
(to pickup latest Docker version)") but without the guard on
$SECRET_PASSWORD. Add the guard to be able to test on CircleCI without
Weaveworks' credentials.
- Ensure we use up to date build container when running tests.
- Parallelise host setup for integration tests.
- Pass some more circle env vars through to ./tools/tests so the scheduler works.
- Gather coverage from multiple shards.
- Create files as the right owner inside the container.
- Parallelise the circle.yaml
- Parallelise the intergration tests using existing machinery
- Build experimental in parallel.
- Use custom scheduler prefix for integration tests, so schedules don't clash with weave.
check before each integration test line is a bit ugly. Can combine them
into one step, but then you don't get metrics on how long each step
takes (in circle).
Integration tests are only run on circle. They checkout the weave
project, and use test helpers from there.
There are just a few basic tests for now, to confirm it works.
