Summary
When a workflow has on.bots: ["github-actions[bot]"] in its frontmatter and github-actions[bot] triggers it, the pre_activation job emits a warning even though the activation succeeds:
User permission 'none' does not meet requirements: admin, maintainer, write
Reproduction
Frontmatter:
on:
bots: ["github-actions[bot]"]
workflow_call:
...Trigger: gh workflow run as github-actions[bot] (e.g. from a quality dispatcher).
Observed: workflow activates and runs correctly, but pre_activation / check_membership logs the warning above.
Root cause
The compiled check_membership step sets both GH_AW_REQUIRED_ROLES and GH_AW_ALLOWED_BOTS as env vars and evaluates them independently. When the actor is a bot, the roles check still runs and warns about none permission, even though the bot passes via GH_AW_ALLOWED_BOTS.
GH_AW_REQUIRED_ROLES is "admin,maintainer,write" regardless of whether roles: is explicit in the frontmatter or defaulted — so there's no frontmatter change that suppresses the warning.
Expected behavior
When an actor matches the bots: allowlist, the roles check should either not run or not emit a warning. A bot actor passing via bots: is an explicit grant; the roles mismatch is expected and not actionable.
Impact
The warning is confusing: it implies a permission failure when the activation actually succeeded. It also can't be suppressed from the caller side.
Repo where observed: elastic/docs-actions — sweep workflows triggered by a quality dispatcher running as github-actions[bot].
Summary
When a workflow has
on.bots: ["github-actions[bot]"]in its frontmatter andgithub-actions[bot]triggers it, thepre_activationjob emits a warning even though the activation succeeds:Reproduction
Frontmatter:
Trigger:
gh workflow runasgithub-actions[bot](e.g. from a quality dispatcher).Observed: workflow activates and runs correctly, but
pre_activation / check_membershiplogs the warning above.Root cause
The compiled
check_membershipstep sets bothGH_AW_REQUIRED_ROLESandGH_AW_ALLOWED_BOTSas env vars and evaluates them independently. When the actor is a bot, the roles check still runs and warns aboutnonepermission, even though the bot passes viaGH_AW_ALLOWED_BOTS.GH_AW_REQUIRED_ROLESis"admin,maintainer,write"regardless of whetherroles:is explicit in the frontmatter or defaulted — so there's no frontmatter change that suppresses the warning.Expected behavior
When an actor matches the
bots:allowlist, the roles check should either not run or not emit a warning. A bot actor passing viabots:is an explicit grant; the roles mismatch is expected and not actionable.Impact
The warning is confusing: it implies a permission failure when the activation actually succeeded. It also can't be suppressed from the caller side.
Repo where observed:
elastic/docs-actions— sweep workflows triggered by a quality dispatcher running asgithub-actions[bot].