Update `container` image references in GitHub Action workflows

[lorengordon]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

I've used Dependabot to update the FROM argument in a Dockerfile, but now I'm starting to use images directly in GitHub Actions, which does not use a Dockerfile. I would still like Dependabot to update the image reference in the workflow file though. Is there a way to do this today? (I did search the docs and issues but couldn't find anything.)

See: https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container

Syntax in the workflow files looks like this:

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container:
      image: node:14.16

[jeffwidman]

This may be what https://github.com/dependabot/dependabot-core/pull/2307 is trying to get at, although that code seems slightly different since it's looking for the docker keyword, not the container keyword... so I may be misunderstanding.

For now, adding new ecosystems / new places to search for updates is on pause... we hope to have a better story there in the not too distant future, but we're just not ready to provide the level of support required for a new ecosystem.

[lorengordon]

That's an alternate syntax, applies to the uses argument... That would work also, though container is nice because you can control more of the docker options.

• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-docker-hub-action
• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer

[lorengordon]

Looks like I could use Renovate instead, they recently released support for this, https://github.com/renovatebot/renovate/pull/16770

[jeffwidman]

Thanks for clarifying and including the docs links.

Glad Renovate can help you get unblocked... hopefully in the not-too-distant future we can support this here as well.

[ssbarnea]

I have the same need, https://github.com/ansible-community/ansible-lint-action/blob/main/action.yml#L26 does not update by itself.

[pascalknupper]

Is there any update on this feature-request?

[thepwagner]

👋 For similar YAML formats, a weird workaround for this is to add:

apiVersion: lol
kind: trollololol

That will trick Dependabot into thinking the file is a Kubernetes resource - so it will find and manage any image: keys in the YAML - https://github.blog/changelog/2022-11-16-dependabot-version-updates-for-docker-image-tags-in-kubernetes-manifests/

Per @franzliedke 👇 - this hack won't work for Actions because it violates Actions' schema.

An idea for this feature, you could align the conditions in the FileFetcher with those in the FileParser. My ideal would be any image: ${stringThatMatchesTheImageSpec} in the directory that I told Dependabot about will be managed. That patch would support GitHub actions, as well as other YAML formats that just happen to use image: as the key - https://github.com/search?q=path%3A.yml+%2Fimage%3A.*%40sha256.*%2F&type=code (docker-compose.yaml seems the common - https://github.com/dependabot/dependabot-core/issues/390)

[franzliedke]

@thepwagner Can you explain how to apply that hack without triggering the GitHub workflow validation? 🤔

[thepwagner]

@franzliedke sorry I hadn't tested it specifically for Actions. My use case is a custom and private YAML format. Nothing is strict about the schema, so the hack works for me. Its effectiveness for Actions was a (bad) assumption.

I left the comment here because:

• it had the most discussion about extracting image: tags from non-Kubernetes YAML files
• my proposed fix of promoting the FileParser style so that ANY image: keys in any YAML schema would work for my use case and Actions at the same time.

I'll update to remove the lie - thanks for testing it! 🧪 .

[thomasleplus]

That's an alternate syntax, applies to the uses argument... That would work also, though container is nice because you can control more of the docker options.

* https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-docker-hub-action

* https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer

FYI the docker:// workaround is not working for me. First I though that the obscure docker container I am using might not part of dependabot docker images index so I switched to an old version of a more mainstream image (amazon/aws-cli:2.15.60). After 48h I am still waiting for a dependabot PR and nothing. I use the same aws-cli image as the parent (FROM) in another repo's Dockerfile and I got a PR from dependabot there already so I know for sure dependabot is aware of the new version and has pushed PRs for it via the docker ecosystem.

Another limitation of uses: is that it doesn't support the run: command so you can't execute anything other than the default entry point of the container, unlike image:.

So I hope dependabot will consider supporting the container as the OP suggested without needing any hack or workaround. Thanks either way for making a great product.

[allanlewis]

Another limitation of uses: is that it doesn't support the run: command so you can't execute anything other than the default entry point of the container, unlike image:.

You can set with.args to set the command, as per docker run <image> <args> - if you want to use a different entry point then it's usually better to write a Dockerfile based on the image you want.