Docker Community Forums

Share and learn in the Docker community.

"Autotest" no longer fires unless "Autobuild" enabled (Org conversion problem?)


(Mark Henwood) #1

We’ve been using Docker Cloud for months (and before that, Tutum) with the following kind of Build Config, with no problems at all:

[1] Branch: master, Docker Tag: latest, Autobuild: Yes
[2] Branch: /.*/, Docker Tag: {sourceref}, Autobuild: No

The outcome of this configuration has always been:

  • Pushes / merges into master start the Autotests; if these are successful the image is pushed with the ‘latest’ tag
  • Pushes / merges into any other branch start the Autotests; no action taken once these are finished

We recently converted to an Organisation (not sure if this is the key). Now, the ‘master’ branch still triggers tests and builds just fine as before, whereas pushes to other branches result in nothing at all.

I have checked and relinked the GitHub webhooks to the Docker Cloud Org repo. GitHub is firing webhooks correctly.

The only way to get the “other” branches to Autotest is to set their “Autobuild” to “Yes”. In other words: If I set Autobuild on the above config line [2] to “Yes”, a push to GitHub fires up the tests and then the image push. This is undesirable because we don’t want to push an image tag for every branch.

The “Autotest” option is set to “Internal Pull Requests”.


(Ryan Kennedy) #2

@mhenwood Thanks for the feedback. The most recent Docker Cloud release updated the Autotest behavior for running tests on branches that build rules have been set up for. Now you can choose to test internal pull requests when the pull comes from the same source repository, or test both internal and external pull requests to include when the pull comes from an outside repository (for example a PR from a user’s fork).

The new options are:

  • Off: No additional test builds. Tests only run if they’re configured as part of an automated build.
  • Internal Pull Requests: Run a test build for any pull requests to branches that match a build rule, but only when the pull request comes from the same source repository.
  • Internal and External Pull Requests: Run a test build for any pull requests to branches that match a build rule, including when the pull request originated in an external source repository.

(Mark Henwood) #3

Thank @pkennedyr - Does that mean that pushes to branches no longer trigger tests? Is it only Pull Requests which trigger now? That would be a shame.


(Pablo Chico de Guzman Huerta) #4

Hi Mark,
We have switched the autotests behavior because it makes things clearer when you have several dockerfiles defined in your repo, and working with pull requests is the most common dev workflow in Github. If you are using a different tool for reviews instead of PRs, you can simulate the previous autotest behavior by enabling “autobuild” on you second build rule, and adding a “push” hook to your git repo like this one:

#!/bin/bash

if [ "$GIT_BRANCH" == "master" ]; then
    docker push $IMAGE_NAME
fi

(Mark Henwood) #5

Thanks @pchico83. That’s helpful. I will implement a hook as suggested.

As it stands the documentation is out of step with this new approach in
that case because it still talks about having pushes trigger builds. Is
there an open source docs repo i can submit corrections to?

Although there is a workaround it’s a shame because we as a team we’re
relying upon every push triggering a test run which of course we still can
but not as a primary function of the CI facility anymore.

Thanks again for your help.


(LRubin) #6

@mhenwood, if you scroll to the bottom of the pages in the docs, there’s now an “edit this page” link. (You can also just file an issue.) All of the docs now live in a central repo at https://github.com/docker/docker.github.io.