I migrated a Trivy scan workflow to a new composite action and pushed it to 9 repos. The workflow files had pull_request and schedule triggers. The YAML was valid. GitHub showed no errors. But the workflows never ran.
The Symptom
After pushing the updated workflow files:
on:
pull_request:
branches: [main]
schedule:
- cron: '0 6 * * *'
I opened PRs to test. Nothing triggered. The Actions tab showed the workflow existed but had zero runs.
The Investigation
The workflow file was correct — syntax validated, triggers were right, the composite action resolved properly. I tested the same file in a fresh repo and it worked immediately.
The difference: the target repos had previously disabled the old workflow via the GitHub UI (Actions → workflow → “…” → Disable workflow). This was done months ago when the old Trivy action was compromised.
The Gotcha
When you disable a workflow in the GitHub UI, it stays disabled even if you:
- Push a new version of the workflow file
- Rename the workflow
- Change the triggers
- Delete and recreate the file
GitHub tracks workflow enable/disable state by the file path, not the file contents. Pushing a new workflow to the same path as a disabled one inherits the disabled state. The UI shows it in the workflow list with no visual indicator that it’s disabled unless you click into it.
The Fix
gh workflow enable trivy-scan.yml -R org/repo-name
That’s it. One command per repo. After enabling, the next PR triggered the workflow correctly.
For the repos that still weren’t triggering after enable, I pushed a dummy commit to force GitHub to re-evaluate the workflow file:
git commit --allow-empty -m "trigger workflow re-evaluation"
git push
Takeaway
If you’re migrating GitHub Actions workflows and the new versions don’t trigger, check if the old workflow was disabled via the UI. gh workflow list shows the state. Disabled workflows stay disabled through file updates — you have to explicitly re-enable them with gh workflow enable.