Why is there a difference between these "tags" in the graphQL schema?

Questions / Help
1

Hello there,

I wanted to keep track of the commit SHA attached to each deploy that I can then reference from a bot I’ve been working on.

To do so I’m running flyctl deploy --remote-only --image-label "deployment-$GITHUB_SHA" -a ${{ matrix.app }} from the GH workflow file.

Then from the bot I want to get access to that label (and thus the SHA). I’ve been playing around with the graphql playground I noticed that if I run this query

{
  app (name: "xxxxxxxx") {
    imageDetails {
      tag
    }
    releases {
      nodes {
        image {
          tag
        }
      }
    }
  }
}

I get the correct output under imageDetails and not under releases.nodes.image.tag where each tag is set to null.

"app": {
      "imageDetails": {
        "tag": "deployment-fee986eb8ae50723fbdf0bbf9ef436676fb84c34"
      },
      "releases": {
        "nodes": [
          {
            "image": {
              "tag": null
            }
          },
          {
            "image": {
              "tag": null
            }
          },

Is this expected or is it a bug? If it is expected, is there any way for me to grab that value for each single release?

2

What what do you see for this query?

{
  app (name: "xxxxxxxx") {
    imageDetails {
      tag
    }
    releases {
      nodes {
        imageRef
        image {
          tag
          ref
        }
      }
    }
  }
}
3

Here it is

"app": {
      "imageDetails": {
        "tag": "deployment-fee986eb8ae50723fbdf0bbf9ef436676fb84c34"
      },
      "releases": {
        "nodes": [
          {
            "imageRef": "registry.fly.io/xxxxxxxxxxxxx@sha256:938636e96628d72b9b248ebec59679f8a21319922bc28d1536938e5cc6bb7046",
            "image": {
              "tag": null,
              "ref": "registry.fly.io/fxxxxxxxxxxxxx@sha256:938636e96628d72b9b248ebec59679f8a21319922bc28d1536938e5cc6bb7046"
            }
          },
4

@michael - did you manage to look into this?

5

:wave: I decided to take a closer look here; but the short version is: the release tracking for images’ tags has been left relatively naive and will likely stay that way for the time being.

The longer context version: We don’t use tags to refer to images, especially for informing historical context in part because it’s unreliable to reference images by tag. This is because a particular image, in terms of container images, can have multiple tags. As an example latest, v1, v1.0 could all associate to one image. You can also reuse tags for images - like how you see projects retagging latest to whatever the newest image is at the time.

Given that context, a release is more reliably associated to a particular image (by its digest) than by a moving-target tag.

Due to these caveats, I wouldn’t recommend using the release image tag from our API this way today.