Dockerfile

kind: dockerfile

Description

The Dockerfile crawler looks recursively for all Dockerfile from a specific root directory. Then, for each of them, it tries to update each Docker image tag found in a 'FROM' instruction.

Updatecli looks for the following file patterns:

  • Dockerfile

  • Dockerfile.*

The automatic discovery behavior can be tuned by providing a YAML manifest with a dockerfile crawler in top-level directive autodiscovery as explained in the "Autodiscovery" page.

Usage

The dockerfile autodiscovery can use with or without manifest.

Without manifest

Without manifest available, Updatecli will enable all default crawlers, including dockerfile.

updatecli diff to run updatecli in dryrun updatecli apply to apply the changes locally

With a manifest

If a manifest is provided, Updatecli will only execute crawlers specified in the manifest such as in the following example

  • updatecli diff --config updatecli.d/default.yaml to run updatecli in dryrun

  • updatecli apply --config updatecli.d/default.yaml to apply the changes

# updatecli.d/default.yaml
name: "[asciidoctor/docker-asciidoctor] Dockerfile autodiscovery using git scm"
scms:
  asciidoctor:
    kind: git
    spec:
      url: https://github.com/asciidoctor/docker-asciidoctor.git
      branch: main

autodiscovery:
  # scmid is applied to all crawlers
  scmid: asciidoctor
  crawlers:
    dockerfile:
      #rootdir: <custom root directory, overriden by scm configuration>
      #
      ## Ignore Dockerfile update matching following rules
      #ignore:
      #  - archs:
      #      - "amd64"
      #    path: "qa/*"
      #    images:
      #      - alpine
      #      - alpine:3
      #  
      ## Only update Dockerfile matching following rules
      #only:
      #  - archs:
      #      - "amd64"
      #    path: "qa/*"
      #    images:
      #      - alpine
      #      - alpine:3
      #
      # auths:
      # Override default dockerfile filematch
      #filematch:
      #  - "Dockerfile.example"

Manifest

Parameters

The crawler dockerfile supports the following parameters:

NameRequiredDefaultDescription

rootdir

current dir

Define root directory to look for Dockerfile files

filematch

["Dockerfile","Dockerfile.*"]

FileMatch allows to override default dockerfile file matching.

only

Define a list of rules to only update a subset of Dockerfile files

only.images

Define a list of images to only update

only.path

Define a list of dockerfile file path to only update

only.archs

Define a list of docker image architecture to only update

ignore

Define a list of rules to ignore update a subset of dockerfile files

ignore.images

Define a list of images to only update

ignore.path

Define a list of dockerfile file path to only update

ignore.archs

Define a list of docker image architecture to only update

auths

Auths allows to specify a list of docker registry credentials

auths.username

Username defines a docker registry username

auths.password

Password defines a docker registry password

auths.token

Token defines a docker registry token

Docker Image Tag

The Docker ecosystem has no versioning guidelines. This means that it’s the wild west out there and pretty much impossible to detect all cases. Hence why Updatecli manifest was created.

That being said we are still interested in an autodiscovery feature that would detect as many cases as possible. This section is about documentation what is covered and what’s missing. Do not hesitate to look at the contributing section

Semantic Versioning

In the Docker ecosystem, many tags look like semver but are not. For instance, node:18.12.1-alpine would match the semver regular expression but the prerelease -alpine is not a prerelease information as per semver convention but a variant of node:18.12.1-buster or node:18.12.1. This means that we would expect a newer version with the -alpine such as node:19.0.0-alpine.

The dockerfile autodiscovery will handle the following scenarios

  • 1 will suggest a version such 2 otherwise stick to 1

  • 1-alpine will suggest a version such 2-alpine otherwise stick to 1-alpine

  • 1.0 will suggest a version such 2.1 otherwise stick to 1.0

  • 1.0-alpine will suggest a version such 2.1-alpine otherwise stick to 1.0-alpine

  • 1.0.0 will suggest a version such 2.1.0 otherwise stick to 1.0.0

  • 1.0.0-alpine will suggest a version such 2.1.0-alpine otherwise stick to 1.0.0-alpine

Any other version pattern such as PEP 440 are ignored in the current state. We are planning to add new versionFilter kinds in the futur as the need raise.

Feel free to:

  1. Open an issue explaining the version pattern you are looking for.

  2. Add a +1 to an existing issue as it helps us to prioritise

  3. Contribute to an existing one as it will move things faster.

Top