Error message for disallowed non-pinned actions should include the actions call stack

[MasterCarl]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Actions Runner

Discussion Details

The error message for disallowed non-pinned actions should include the actions "call stack". Right now, in a repository with dozens of actions, it's very hard to find out which action dependency might use a non-SHA version. Only when debug logging is activated, the logs point to which action contains the version tag in question.

We got the following message:

The action actions/setup-node@v4 is not allowed in $REPOSITORY because all actions must be pinned to a full-length commit SHA.

The error message should include the file and line number where the action is referenced, and ideally also which workflow(s) call it, since the action might be defined in a different repository altogether.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[abinaze]

Hi @MasterCarl,

This is a very valid concern, and I’ve run into the same issue in larger repositories.

Right now, the error message:

“The action actions/setup-node@v4 is not allowed…”

is technically correct, but not very actionable. In setups with multiple reusable workflows and nested actions, it becomes difficult to trace where that non-pinned reference is actually coming from.

The core problem is that GitHub reports the violation at the resolution level, but doesn’t expose the execution path that led to it. So if the action is:

• used indirectly via another action
• defined in a reusable workflow
• or coming from a different repository

you’re left guessing unless debug logging is enabled.

Including a call stack (or even partial trace) would make a big difference. For example:

• workflow file + line number where the action is referenced
• whether it’s coming from a reusable workflow (uses:)
• the chain of calls leading to the violation

Even something minimal like:

• .github/workflows/build.yml:23
  would already reduce a lot of friction.

As you pointed out, debug logs do expose this information, which suggests the data is already available internally — it’s just not surfaced in the default error output.

From a usability standpoint, this is one of those cases where:

• the system enforces a strict security rule (pinning to SHA)
• but doesn’t provide enough context to fix violations efficiently

In larger CI setups, that turns what should be a quick fix into a time-consuming search problem.

Your suggestion to include both the location (file/line) and the workflow call chain makes a lot of sense, especially as more teams adopt reusable workflows and stricter policies.

This would significantly improve debuggability without weakening the security model.