1.12.3 broke autobuilds - Dockerfile pathing changed

Docker Hub
1

Dockerfile source paths used to be relative to the location of the Dockerfile used in the Docker Cloud Autobuild “Dockerfile location”. Now it appears they are relative to the root of the github repository.

While I like the change, it broke all my builds and Dockerfiles!

It seems the change happened with 1.12.3 as builds from 1.12.2 a couple days ago were fine.

Example:

github repository filesystem:
/project/src/file.txt
/project/Dockerfile

Autobuild “Dockerfile location” is defined in Docker Cloud as:
/project/Dockerfile

Dockerfile:
FROM xyz
COPY src target

The above used to work.

Now my Dockerfile must be:
FROM xyz
COPY project/src target

2

Results are becoming inconclusive - I’m uncertain now what the real root cause is.

3

I have also noticed some changes with builds:

  • My source mapping regex for branches stopped working and needed to be changed through trial and error
  • The “/Dockerfile” location path seems to get ignored; it matches all files named Dockerfile in the repo
4

@jthayercl might I have the docker repo where this is happening?

5

@phubar might I have the docker repo where this is happening?
Also, could your share the regex that you were using before and after this issue?
Note sure if I understand the “/Dockerfile” location complain, could you give an example?

6

I just posted those details here: Build configuration: Match any branch

Regex before: ?!master
Regex now: (?!master)[.]*

7

@phubar could I have the docker repo? I didn’t find it in your other comment. If this is a breaking change, we will need to rollback to the previous behavior

8

https://cloud.docker.com/app/veri/repository/docker/veri/web/general

9

Thanks @phubar . The regexp issue is a regression that we already had identified. It will go live asap, I will let you know when its gets to production so you can rollback your change.
Respect to the dockerfile location, your are right, we have changed the way autotests works. More information here https://docs.docker.com/docker-cloud/builds/automated-testing/

The way it works now is based on pull requests. When you open a pull requests agains master, it creates an autotest action for every build rule defined for master. In your case, this is “/resources/docker-cloud/builds/dev-db/” and “/Dockerfile” (maybe you could remove the first build rule). This includes build rules with “autobuild == False” at the moment, although it could make more sense to ignore these build rules for autotests.

10

I have recreated the problem with a sample public github repository and docker hub repository.

Github:
JohnThayer22/docker-test

Docker:
frogpower/docker-test

This builds fine locally with current directory /project and :
docker build -f Dockerfile_one .

It fails to build in Docker Cloud autobuild with Dockerfile location /project/Dockerfile_one.
“lstat one/src: no such file or directory”

11

Love the change to make it dependent on pull requests! We definitely need the db-build that has autobuild turned off though; we use it to build a new db image on demand (for dev) whenever the db schema changes. It would make sense to not run it automatically with pull requests - I could have control over that by duplicating it, changing the tag, and setting autobuild to true.

12

@phubar Yes, makes sense. The change to ignore autobuild==false will go live on the next release

1 Like
13

@jthayercl We have found the issue with your build rules. We are working on a release for next Tuesday that supports to specify the “build context” for a build rule. Before this release, the “build context” was always set to the basedir of your dockerfile location.
We had a miss-coordination with a UI release, and between monday and tuesday, build rules were created with “build context” equals to “/” by default. This is why for some build rules you are seeing a weird behavior.
You can hold on until next Tuesday to specify the “build context” on your needs, or delete these rules, save your build configuration, and recreate them again, and they will behave as normal (setting the “build context” to the basedir of the dockerfile location).
Sorry for this inconvenience.

14

Thanks for finally confirming the break. Thanks for providing a workaround. I’ll certainly give the workaround a try.

I’m excited to soon be able to specify the build path.

1 Like
15

I have performed your workaround:

  1. Delete build rule
  2. Save
  3. Recreate build rule
  4. Save
  5. Build

And it worked this time as expected with the original behavior. Thanks!

1 Like