metadata-action icon indicating copy to clipboard operation
metadata-action copied to clipboard

Add option to choose between git or workflow context to generate metadata

Open lucacome opened this issue 4 years ago • 7 comments

Behaviour

I have a workflow that checks out the latest tag and rebuilds the Docker image if the base image was updated. Context info contains info from master:

Context info
  eventName: schedule
  sha: 1c0577d958b4b4bed278593872a3c29f02981a0d
  ref: refs/heads/master
  workflow: Update Docker Images
  action: meta
  actor: lucacome
  runNumber: 134
  runId: 1335539062

Steps to reproduce this issue

  1. Run the workflow on a schedule
  2. Checkout a tag
  3. The sha is not the correct one

Expected behavior

org.opencontainers.image.revision contains the sha from the tag that was checked out

Actual behaviour

org.opencontainers.image.revision contains the sha from the latest commit on master

Configuration

  • Repository URL (if public): https://github.com/nginxinc/kubernetes-ingress/blob/master/.github/workflows/update-docker-images.yml
  • Build URL (if public): https://github.com/nginxinc/kubernetes-ingress/runs/3877415389?check_suite_focus=true#step:11:20
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          ref: v${{ needs.variables.outputs.kic-tag }}

       ....
 
      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: |
            nginx/nginx-ingress
            ghcr.io/nginxinc/kubernetes-ingress
          flavor: |
            latest=true
            suffix=...not relevant...
          tags: |
            type=raw,value=${{ needs.variables.outputs.kic-tag }}
            type=raw,value=${{ steps.tag.outputs.short }}
          labels: ...not relevant...

Logs

logs_11965.zip

lucacome avatar Oct 13 '21 02:10 lucacome

@lucacome

a workflow that checks out the latest tag

git sha used by the metadata action is the one from the context when the workflow is triggered (before any job). So yes in your case it might not be accurate because the ref is desync from the context.

What you can do is overriding this label with something like:

          labels: |
            org.opencontainers.image.revision=${{ steps.kic.outputs.sha }}

See also https://github.com/actions/checkout/issues/281

crazy-max avatar Oct 13 '21 03:10 crazy-max

@crazy-max yeah that would work, I just thought it would be more consistent to get the info from the actual commit/tag/branch that was checked out since there's always a checkout in the job, but probably I don't have the full picture of all the different tags inputs.

Maybe an input flag to enable getting the info from the current commit? Just throwing it out there 😄

lucacome avatar Oct 13 '21 03:10 lucacome

@lucacome

there's always a checkout in the job

Not always. You can build a Docker image using a Git context so it does not require the checkout step.

Maybe an input flag to enable getting the info from the current commit? Just throwing it out there 😄

Yeah I understand what you mean but the action heavily relies on the current context via the hydrated Octokit client (aka @actions/github).

I will think about it, maybe something like:

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v3
        with:
          context: <workflow|git>

crazy-max avatar Oct 13 '21 03:10 crazy-max

Not always. You can build a Docker image using a Git context so it does not require the checkout step.

Ah good to know.

I will think about it, maybe something like:

yeah something like that would be great!

lucacome avatar Oct 13 '21 06:10 lucacome

I will think about it, maybe something like:

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v3
        with:
          context: <workflow|git>

If I could +1 this, I'd be very much interested in it too!

DanHorrocksBurgess avatar Dec 02 '21 17:12 DanHorrocksBurgess

+1 for that, we have a workflow that uses workflow_dispatch where we pass the ref through an input. The workflow context is always for master, but the code itself is for a different commit.

JCMais avatar Jan 13 '22 19:01 JCMais

So if you use the actions/checkout@v2 with ref - What ultimately is built? While I understand that you could run this without a checkout I haven't seen a single example in any of the documentation to suggest this is a legit workflow. I feel the default should be to inspect for a checkout and respect it as the incoming version head.

rh0dium avatar Apr 18 '22 19:04 rh0dium