A team deploys an agent that is supposed to trigger a CI workflow whenever it pushes a commit to a feature branch. The agent successfully pushes commits, but the CI workflow never runs. The workflow file specifies on: push with branches: ['main', 'release/**']. What is the root cause?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The CI workflow is like a bouncer with a guest list that only says 'main' and 'release/**' — the agent's feature branch wasn't invited. The trigger fired, but the branch filter dropped it. The fix is to add the agent's branch pattern to the workflow's branch filter, or to configure the agent to push to a branch that is already on the list.
Full explanation below image
![2048x1536 landscape infographic titled 'CI Workflow Event Trigger Misconfiguration'. Center: GitHub Actions workflow YAML snippet highlighting on: push with branches: [main, release/]. Left: agent pushing commit to 'feature/fix-auth' branch, push event shown as packet, workflow trigger evaluation step showing feature/fix-auth NOT matching filter, red X, workflow never runs. Right labeled 'FIX': updated YAML showing branches: [main, release/, feature/], same push now matching, green checkmark, workflow runs. Bottom: branch pattern matching legend showing glob syntax. GitHub dark palette.](/media/github/gh-600/GH-600-e3-q013-infographic.webp)
Full Explanation
GitHub Actions workflow triggers support branch filters that restrict which branches activate the workflow. In this scenario, on: push with branches: ['main', 'release/'] means only pushes to branches named main or matching the release/ glob will trigger the workflow. Feature branches (e.g., feature/fix-auth, agent/refactor-db) do not match either pattern, so their push events are silently ignored — no error is produced and no workflow run appears.
There are two valid fixes: (1) add the agent's branch pattern to the workflow's branch filter (e.g., 'feature/' or 'agent/'), or (2) configure the agent to push to a branch that is already covered.
Option A (token missing workflow permission) would prevent the agent from modifying workflow files, not from triggering existing workflows via push events. Triggering a workflow via push requires write access to the repository, not the workflow scope.
Option C (rate limiting) is unlikely in normal usage and would manifest as intermittent failures with rate limit error messages, not a consistent absence of workflow runs.
Option D (pull_request event required) is a distractor. The workflow already uses push, which is the correct event type for commit pushes. The issue is the branch filter, not the event type.
Always verify that the workflow's branch filter includes the branches the agent will push to.