Use Docker 17.04

[jmccann]

Update to using docker 17.04 in support of #119

Also trying to utilize read of tags from file (courteous of #121)

I split this into 2 commits. Feel free to let me know if you don't like how I'm doing the dynamic tagging. I can remove/rework it.

[bradrydzewski]

So ... even though I think sourcing tags from file is awesome (thanks for the PR) ... I'm realizing that we cannot use the .tags file for this plugin. This is because we will soon start publishing os/arch docker images, such as plugins/docker:linux-arm64, plugins/docker:linux-amd64-17, etc.

So I think we need to define the tags inline still:

tags: [ "latest", "17", "17.04" ]

The good news is that starting in 0.6 the signature will no longer be required. This means that we can update the tags in the yaml without breaking the build and having to re-sign the yaml, which was one of my initial concerns.

[jmccann]

That is fine.

Are we OK then with tags matching exactly the version of Docker for this plugin from now on? Or should it be a combination of plugin/docker version?

tags: [ "latest", "1", "1.13", "1-17", "1.13-17", "1-17.04", "1.13-17.04" ] # all combinations
tags: [ "latest", "1", "1.13", "1.13-17", "1.13-17.04" ] # append docker tags only for minor version tags

I'm just creating some examples based from ant docker image which reflects ant/java version in it's tag. https://frekele.github.io/docker-ant/

[jmccann]

Just curious how you plan to do OS/arch. I'm imagining a matrix of builds for each os/arch in which you could dynamically generate tags?

workspace:
  base: /go
  path: src/github.com/drone-plugins/drone-docker

pipeline:
  test:
    image: golang:1.6
    environment:
      - CGO_ENABLED=0
    commands:
      # Disabled: main.go:99: cli.StringSlice composite literal uses unkeyed fields
      # - go vet
      - go test -cover -coverprofile=coverage.out
      - go build -ldflags "-s -w -X main.build=$DRONE_BUILD_NUMBER" -a -tags netgo

  tags:
    image: golang:1.6
    environment:
      - VERSION=1.13
    commands:
      - DOCKER_FROM=$(grep FROM dockerfiles/${ARCH}/Dockerfile)
      - DOCKER_FROM=$${DOCKER_FROM#*:}
      - DOCKER_VER=$${DOCKER_FROM%-*}
      - echo -n "${ARCH}-$${VERSION},${ARCH}-$${VERSION%%.*},${ARCH}-$${VERSION}-$${DOCKER_VER},${ARCH}-$${VERSION%%.*}-$${DOCKER_VER}" > .tags
      - cat .tags

  publish:
    image: plugins/docker
    repo: plugins/docker
    dockerfile: dockerfiles/${ARCH}/Dockerfile
    when:
      branch: master
      event: push

matrix:
  ARCH:
    - linux-arm64

[bradrydzewski]

Are we OK then with tags matching exactly the version of Docker for this plugin from now on? Or should it be a combination of plugin/docker version?

We actually already pin the plugin tag to the docker version. 1.13 was the previous docker version. So we can probably just update to the following:

tags: [ "latest", "17", "17.04" ]

If we get into a situation where we need something more fine grained we could start appending the build number. Not sure I want to start snapshotting that many images, although that being said, the plugin is stable and changes are much less frequent than before ... my gut would be to wait and see if this is necessary

tags: [ "latest", "17", "17.04", "17.04-build.${DRONE_BUILD_NUMBER}" ]

Or alternatively add and increment a minor version number

tags: [ "latest", "17", "17.04", "17.04.1" ]

Just curious how you plan to do OS/arch. I'm imagining a matrix of builds for each os/arch in which you could dynamically generate tags?

I'm not entirely sure yet. We will provide the operating system and architecture as environment variables. Right now we define DRONE_PLATFORM=linux/amd64 but could provide split into DRONE_OS and `DRONE_ARCH. So the example you provided would work.

[jmccann]

@bradrydzewski Sorry I took my time getting this simple update made. Let me know if there is anything else needed.

[mrueg]

@jmccann Could you update to 17.05 when dind is released for it? That provides the multi-stage build feature.