Open alex opened 1 year ago
Yeah, I can reproduce this. Currently the only way to update composite actions is to configure the directory containing the action.yml
file explicitly.
But even if not explicitly configured, we should also parse any local actions referenced by any parsed workflow files, so that you can get all updates for a specific dependency together like you expected.
@deivid-rodriguez thanks! when you say to configure the directory with the action.yml
, you mean one entry per composite action, is that right?
Yes, that's what I mean.
As I understand (I also bumped into this problem), there's no "standard directory" for defining internal actions (I don't think .github/actions/
is standard), and therefore dependabot simply does not assume your actions path. I really don't think this is a bug 🤔 (is it labeled as bug incorrectly? @deivid-rodriguez)
I also have a similar issue with a private GitHub repo hosting multiple actions at e.g.:
/.github/dependabot.yml
/.github/workflows/my-shared-workflow.yml
/action-foo/action.yml
/action-bar/action.yml
... # and a dozen of other actions
With that repository and dependabot configured with github-actions
and directory: "/"
, what I would like to see is Dependabot looking for all valid action.yml files and updating those, on top of updating the actions within my-shared-workflow.yml
But currently instead what happens is that dependabot will only search for updates within my-shared-workflow.yml
.
Realistically I don't think dependabot will ever sweep the whole repo for valid GH Actions files, but instead I expect one of these issues being fixed (so we can have simplify our dependabot config when it has multiple directories with the same ecosystem): #2178 #1582
I believe it's correct that there's no standard directory for internal actions, however, nonetheless they could be discovered by recursively following local uses:
from a workflow.
I can label as a feature request, probably a better fit! My intention to support this was to do what @Alex suggests, since that's what we already do in similar situations.
Hi! Can you try using multi-directory support and grouping rules? That should work to update composite actions. cc @abdulapopoola
Thanks! https://github.com/pyca/cryptography/pull/10921 this definitely makes it less verbose. Once there are wildcards we'll be able to do .github/actions/*
I assume, at which point I think this will be sufficient for us.
Yes, that's what I mean.
@deivid-rodriguez Can you provide an example configuration for an action located at .github/actions/abc/action.yml
?
I no longer maintain this repo, but you can see a few linked commit and PRs with the current workaround.
@carlincherry, are you able to give an example of how the multi-directory would look here? Would it be the below?
version: 2
updates:
- package-ecosystem: "github-actions"
directories:
- "/"
- "/.github/actions/*/action.yaml"
schedule:
interval: "daily"
There isn't a standard, but like many users we use .github/actions/[name]
- which means the action.yaml
file is at .github/actions/[name]/action.yaml
.
I'm concerned that Dependabot may still be looking for a .github/workflows
folder with this approach, and it's a little hard to test.
Is there an existing issue for this?
Package ecosystem
github actions
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
Updated dependency
actions/cache
What you expected to see, versus what you actually saw
I expect https://github.com/pyca/cryptography/blob/main/.github/actions/cache/action.yml#L33 to be upgraded by https://github.com/pyca/cryptography/pull/8365, but it's not.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response