Using resource in "get" doesn't populate /tag correctly

[fatih]

Hi,

First I have a file called image_tag with the following content:

123abc

I'm using the resource in get and then as put in another job, a simplified example.:

jobs:
  - name: build
    plan:
      - task: build
        file: build.yml
      - put: my-image
        params:
          build: build
          tag: build/image_tag
  - name: deploy
    plan:
      - get: my-image
        passed: [build]
        trigger: true    
        params:
          skip-download: true
      - task: deploy
        file: deploy.yml

So according to the README, it says:

/tag: The tag of the repository that was fetched.

However when I fetch it I see this:

root@f688e206-4802-4915-4082-7ad25f7dfa2e:/tmp/build/b0d51b9f/my-image# cat tag
latest

But if you look at my jobs, and especially at the put params, you see I don't use latest. Instead I'm using my own tag file with the content 123abc.

I assume that with get, the content of /tag should also be 123abc, but right now it's not.

Do I miss something or is /tag always latest?

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #134039337 Using resource in "get" doesn't populate /tag correctly

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[ls-yann-david]

I'm currently hitting the same bug and that prevents me from finishing my CD flow 😢

Any idea when something is going to be done for that?

[VanAxe]

After a bit of digging, this seems to be a problem (or feature) with the Docker architecture. Pulling an image only pulls the tag used for pulling into the metadata available to docker inspect.

The check script indeed checks for latest which is passed to the in script, which pulls latest image. Concourse uses the digests as refs to version the resource.

It seems that every tag is fundamentally associated with a "different image" (notice the scare quotes). If you pull two different tags that happen to be composed of all the same layers, the Docker CLI will be nice enough to collate that together into the RepoTags metadata object, but it seems that this information is completely artificial not intrinsically available.

I've been looking the Docker API and there doesn't seem to be a way to either get all the tags associated with a given digest, since a digest will only ever represent a single tag, or get all the other tags also available for a given image.

So, in a nutshell, since Docker seems to only use digests internally to track collections of layers and associates a tag with a digest, and every tag and digest is unique, there is nothing available to link tags together for an identical collection of layers short of downloading all the tags and layers and checking yourself if different tags have the same layers (which I assume is what the Docker CLI does).

TL;DR, you have to track your own tag some other way. :/

This seems pretty bleak, but if someone thinks of something, I'm all ears.

[hugowetterberg]

I've solved this in my pipelines by passing the tag to a semver resource and then pass that around instead.

[chendrix]

Hi there,

Sorry this took so long to be responded to from the Concourse team but @VanAxe's #78 (comment) is exactly right.

Tags are not lightweight metadata attached to a digest, and the tag that's received is always the tag that's specified in your resource definition.

[mattdodge]

Is this still the case for this issue? I can't believe there's not a better way to push a docker image with a custom/dynamic tag and then deploy that image.

My use case is a pretty straightforward one (I think...). I want to push a docker image that has a tag of the repository's commit SHA. I would expect that if I do a get on this docker-image resource (especially immediately after the put) I can see the tag I just pushed to. But the /tag file always just has "latest".

We need to rely on resources to pass information between jobs - and if the docker-image resource can't maintain information about tags, then what is the alternative? The semver option is an interesting hack but is also super inconvenient as it makes you conform your tags to some kind of major.minor.patch format. Am I missing something or doing something wrong? Or is there a better way I'm not thinking of?