Support nested composite actions #302
Conversation
br3ndonland
force-pushed
the
nested-composite-actions
branch
4 times, most recently
from
bffe630 to
e76ce70
Compare
To reference metadata about composite actions, GitHub Actions provides the `github.action_` context, including `github.action_path`, `github.action_ref`, and `github.action_repository`. GitHub Actions supports nested composite actions with a recursion limit of 9 (9 nested composite actions). Unfortunately `github.action_` values are not propagated correctly when running nested composite actions. This is a bug in the GitHub Actions runner. The suggested workaround is to use inputs to set the correct values. This commit will implement the suggested workaround. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context actions/runner#2473 (comment) pypa#299
br3ndonland
force-pushed
the
nested-composite-actions
branch
from
e76ce70 to
8a35517
Compare
|
Thanks for looking into this! I was suspecting it'd come to using extra inputs. I'm somewhat hesitant to accept this. Earlier, I posted thoughts stating that perhaps this should be declared unsupported instead: #299 (comment) / #290 (comment). My reasoning is that I discovered that using the action like this usually indicates that people perform building the dists in the job that has an elevated OIDC privilege, by embedding both their build automation and calling this action into their composite action. I've been discouraging this for as long as trusted publishing existed, which is the reason such setup was never tested in CI or just considered. I feel like if we implement this hack, this would signal to the end-users that doing so is encouraged, which is completely opposite of what I'd like to teach them. |
|
@webknjaz thanks for sharing your thoughts on this. I would agree - I think it's preferable not to support nested composite actions, given both the security considerations and the confusing bug reported in actions/runner#2473 (comment). I think there could be more problems that could arise if we implemented the I'm going to convert this to a draft for now. If you decide not to support nested composite actions, feel free to close this. It would be helpful to state in the README that nested composite actions are not supported. |
|
Yes, I was thinking about documenting it. And looking into more cases like SBC-Utrecht/pytom-match-pick#241 (comment), I was even thinking that we should just enumerate a very strict set of supported scenarios. Especially, when there's no way to test them on our side. |
|
Apparently, there's a cleaner hack: #304. |
I'm not sure how #304 applies. Are you suggesting that people run nested composite actions inside of containers? That's what actions/runner#2185 is showing. Also, this PR is only changing |
|
Oh, I must've confused these cases, and it turned into “the same thing” in my head… |
|
So I've made a documentation attempt @ 7252a9a. Let's close this one, I suppose. Thanks for looking into it! |
Description
To reference metadata about composite actions, GitHub Actions provides the
github.action_context, includinggithub.action_refandgithub.action_repository.GitHub Actions supports nested composite actions with a recursion limit of 9 (9 nested composite actions). Unfortunately
github.action_values are not propagated correctly when running nested composite actions (actions/runner#2473 (comment)). This is a bug in the GitHub Actions runner.Changes
This PR will implement the suggested workaround from actions/runner#2473 (comment). The action will use inputs to set the correct values.
Related
github.action_repositoryandgithub.action_refare empty inrunfor composite actions actions/runner#2473 (comment)github.action_repositoryandgithub.action_refare not promised for composite actions github/docs#25336 (comment)