Dockerfile support about gitness HOT 15 CLOSED

Yes, definitely a change we could make. I think we would still want to clone the code into a container and then execute docker build. The flow could look something like this:

Step 1: if no .drone.yml exists in GitHub check for a Dockerfile
see https://github.com/drone/drone/blob/master/pkg/handler/hooks.go#L105

Step 2: if a Dockerfile exists we could use a default build script designed to build Dockerfiles
see https://github.com/drone/drone/blob/master/pkg/handler/hooks.go#L125

The default build script could look something like this:

image: docker
script:
  - docker build .

We could even tag the image to match the name of your GitHub repository.

image: docker
script:
  - docker build -t {{ .Owner }}/{{ .Name }} .

We would also need to run Docker in privileged mode for this to work. We added a flag for this (which I just noticed isn't spelled correctly), anticipating such a request, but it isn't implemented yet. Should be a simple fix.

see https://github.com/drone/drone/blob/master/pkg/model/repo.go#L93
and https://github.com/drone/drone/blob/master/pkg/build/build.go#L306

Some additional design considerations for this feature are:

• would we want to push to the index at the end of this process
• where do you define the docker push target?
• how do you handle tags (ie myapp:1.1)

What do you think of the proposed solution, and additional design questions?

from gitness.

would we want to push to the index at the end of this process

I would want this to be optional and default to "don't push".

from gitness.

@bradrydzewski

Step 1: if no .drone.yml exists in GitHub check for a Dockerfile

yes, but if there is a .drone.yml file, you should still allow

script:
  - docker build .

We would also need to run Docker in privileged mode

Because of http://blog.docker.io/2013/09/docker-can-now-run-within-docker/?

Note that in the upcoming 0.9 I think docker containers will be able to talk to the daemon and spawn containers, and it should also be possible today without privileged mode if the host listen on tcp:// and you just talk to it over the container interface. Another possibility is to launch docker build from the host: but that would mean you need to clone the source on the host.

would we want to push to the index at the end of this process

maybe you could run a registry as a container within the drone install, that would allow developer to consume continuous image build as well as stable version from the main docker index.

where do you define the docker push target?

maybe optionally in .travis.yml

how do you handle tags (ie myapp:1.1)

maybe optionally in .travis.yml and default to {{ branch }}@{{ gitrev }}?

What do you think of the proposed solution, and additional design questions?

Sounds like we have a plan :)

from gitness.

We could even tag the image to match the name of your GitHub repository.
docker build -t {{ .Owner }}/{{ .Name }}

I like this; though, I wonder if we shouldn't add the branch/ref as well since you could be building a PR and without the ref, multiple PRs might step on each other.

from gitness.

After getting my team situated with Drone this week I'm in favor of this change. If you haven't started on it yet @bradrydzewski I'll start tackling it tonight/tomorrow. I think it will add a lot.

from gitness.

I'm definitely in support of drone building and pushing docker containers to the repository.

I think there may be a few potential issues using a Dockerfile in place of a .drone.yml. For example, how do we declare our notifications? emails? hipchat? deployment targets? pushing to index?

What if my build requires a database? Or a queue server? The recommended Docker approach is to run these services in separate containers and link together. This orchestration cannot be represented in a Dockerfile.

I'm not trying to be a pain here. I'd just hate for you to code a solution and realize there's no way to notify someone when a build fails! Let's talk through some of the items listed above and see if we can find a resolution.

from gitness.

@bradrydzewski I was only suggesting to infer the script of .drone.yml with docker build . if there is a Dockerfile, you still need a .drone.yml for all the reasons you mentioned.

My current and limited understanding is that drone wrap the script: with a docket run, it would be nice to allow docker build (which is nothing but a series of docker run/commit associated to a context).

I'm not sure if you absolutely need to run docker in docker with privilidged mode to allow that, running docker -H $DOCKER_HOST:4243 build . on a fresh clone would work.

What do you think?

It sounds like #14 would help too and allow drone to build itself w/ drone :)

from gitness.

My understanding was also in line with that. The .drone.yml definitely needs to exist, but the image and optionally script fields can live inside of a container.

from gitness.

@proppy that for the clarification 👍 I misread the original comment. too much caffeine, too little sleep :)

I like the idea of linking port :4243 inside the container in order to execute the docker build. It avoids running Docker daemon in Docker; it avoids privileged mode; but it still clones the code into a container which is consistent with how we would build non Docker projects.

We already link ports here:
https://github.com/drone/drone/blob/master/pkg/build/build.go#L181

It could be as simple as adding host port :4243 to the list

Long term we should think about cleaning up after the build and removing old images or containers, to avoid disk filling up after a bunch of builds.

from gitness.

Long term we should think about cleaning up after the build and removing old images or containers, to avoid disk filling up after a bunch of builds.

Perhaps with an eye towards allowing this to be configurable such that by default, you get a sane amount of builds that stick around long enough for you to be able to debug failed builds, etc.

Also, would be very cool if a build could automatically be cleaned up if the associated branch was deleted or if the associated PR was was merged.

from gitness.

@whitlockjc was able to get Drone running in Docker:

docker run -v /var/run/docker.sock:/var/run/docker.sock -p 8080:80 -d whitlockjc/drone

here is where we link external database containers:
https://github.com/drone/drone/blob/master/pkg/build/build.go#L321

maybe we could link the sockets here as well:

host.Links = append(host.Links, "/var/run/docker.sock:/var/run/docker.sock")

anyone want to give this a try? I'm going to be working through the list of PRs and improving our documentation, so I won't get to this for a few days.

NOTE: for testing this features I recommend using our cli. You can run drone -v build . from the root of your repository to test locally. This can be much faster than testing via the website.

from gitness.

please reference issue #114
we are hashing out some of the specifics

from gitness.

I'm definitely in support of drone building and pushing docker containers to the repository.

Fantastic news - that's exactly what we'd like to do as well.

from gitness.

this can be considered closed based on work in the 0.4 branch (upcoming release). We have a Docker plugin that can run in privileged mode (Docker in Docker) to build and push images. We also have the ability to mount volumes on the host machines (such as the Docker unix socket).

the ability to build and publish images is much stronger in 0.4

from gitness.

Hi bradrydzewski,
i used follow code to build image:
- build -f Dockerfile_local .
i got error like:
unable to evaluate symlinks in Dockerfile path: lstat /python3/src/xxxx-xxxxx.xxxxxxxxx.com/xxxx/Pubhub_Test_Drone/Dockerfile:
so it looks it still find the Dockerfile rather than Dockerfile_local

could you please tell me if i can use specify dockerfile?

thank you very much

from gitness.