Add option to choose between git or workflow context to generate metadata
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
- Run the workflow on a schedule
- Checkout a tag
- 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
@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 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
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>
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!
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!
+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.
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.