Can an action get the path of the workflow event

Can an action get the path of the event that triggered the workflow to run?

Assume the workflow is as follows

      - path/to/file

    runs-on: ubuntu-latest
      - uses: actions/checkout@v2
      - uses: user/log-event-path@v1.0.0

Would the user/log-event-path action be able to determine the event path by querying @actions/core or @actions/github etc…?

  • The action runs using node12.

I guess on push or pr events the action could find a file in the diff tree, and assume it’s the event path.

Then it’s the workflow developers responsibility to restrict the event to only trigger on one path.

Still it would be good if there was a github.context.event.path endpoint or something.

No that wouldn’t work (be reliable), because there could be multiple files in the one commit. The workflow would be triggered, but we still couldn’t be sure witch file corresponds to the event path.

Perhaps get the workflow file that triggered the action. Then parse it for the event path.


In your custom JavaScript action, you can wrap the “Get a commit” API.
From the response context of this API, you can see all the changed files contained in this commit are listed in the “files[ ]” object (a JSON array).

If you want to list the files on a pull request, you can wrap the “List pull requests files” API in your action.

Yes but that does not help.

The issue is in determining which of the changed files is the file that triggered the workflow (and the action) to run.


At first, you can list all the files contained in the specified commit.
Then use the patterns you set on the path filters to compare with the path of each file in the list.
The files that can match the patterns are the files that triggered the workflow run. The matched files may be one or more.

Yes, but I’m talking about a published action. If it was just for me I’d know what the path/s where already.

If github does not provide an event_path property to the action, I think the only option is as I mentioned above; Find and read the workflow file that called the action, parse it for any possible paths, and then filter against the commit file paths.


but I’m talking about a published action.

For a published action, the authors had designed that what the action can do or not.

If you are not clear what things an action can do, you can view the README and the source codes of the action, or contact the authors to get more details information.

If you want to expand the features of an action, you can fork the repository of the action to your account and re-develop the action as your demands.

Again, if you want to view which files triggered the event, at first you need to list all the changed files contained in the commit, then compare with the patterns of the path filters.
To get the list of the changed files, no matter in an action or directly in the workflow, you can run the API I mentioned above, or git commands (such as git diff).

I am the actions author.


I am the actions author.

You just need to improve the source code of the action to add the new features you require, then publish a new version of the action.

Ok thanks mate, I’ll take it from here.