Tag: ${DRONE_COMMIT_SHA:0:8} not always a string?

Drone Support
1

Came across an odd issue yesterday on one of our builds. This might be a problem with the docker plugin, but I figured I would start here first.

The error in the build was this:

+ /usr/local/bin/docker tag 04040944c58546fe42ab4ae073f9ad9140eb3e30 repository.mycompany.dev/brand-sites-template:4.040944e+06

Error parsing reference: "repository..mycompany.dev/brand-sites-template:4.040944e+06" is not a valid repository/tag: invalid reference format

time="2020-06-11T19:49:09Z" level=fatal msg="exit status 1"

The build step is defined as:

steps:
  - name: publish-dev
    image: plugins/docker
    settings:
      username:
        from_secret: docker_username
      password:
        from_secret: docker_password
      repo: repository.mycompany.dev/brand-sites-template
      registry: repository.mycompany.dev
      dockerfile: Dockerfile
      tags: 
        - development
        - ${DRONE_COMMIT_SHA:0:8}
    when:
      branch: 
        - development
      event:
        - push

It was the first time we saw this, and after quite sometime, came across this post:

Which confirmed my suspicion that something interesting was happening with the tag value. As per the issue above, I changed the build step to this:

steps:
  - name: publish-dev
    image: plugins/docker
    settings:
      username:
        from_secret: docker_username
      password:
        from_secret: docker_password
      repo: repository.mycompany.dev/brand-sites-template
      registry: repository.mycompany.dev
      dockerfile: Dockerfile
      tags: 
        - development
        - "${DRONE_COMMIT_SHA:0:8}"
    when:
      branch: 
        - development
      event:
        - push

And sure enough the build worked - of course the SHA value was now different, so I cannot confirm that that change fixed it.

Has anyone else seen this, and should double quotes be used when tagging a build and using a drone variable?

We are running drone self hosted, version drone:latest

Thanks
John

2

Hi John, this behavior is the result of the yaml parser / specification and its underlying ambiguity. If the string is also an integer (including an integer with leading zeros) the yaml parser unmarshals the value as an integer which in turn strips leading zeros. So if the string value could be an integer, or be interpreted by the yaml parser as an integer (preceding zeros), you should quote it accordingly.

3

Thanks for confirming Brad. Much appreciated. We will be applying quotes on our builds when this particular pattern is used.

Thanks!
John

4

Just adding a further note as I see this post has been useful.

Take what is said here literally. The issue is with the yaml parser, which means that anywhere else where you are using this variables in your build file could also lead to this issue occurring. Its not just in the tags section as I originally had thought.

In our build files we had other places where drone vars were being used and eventually saw this same issue happen again. Since then we’ve used quotes around these vars to ensure we don’t have a build error.