Entrypoint is the workflow name

[ianlewis]

At it stands the provenance invocation.entryPoint is set to the workflow field from the Github Actions workflow. This is the name of the calling workflow or the path if the name is not set.

This seems wrong to me. I think the path to the calling workflow yaml file would be more useful but I'm not sure. We could get from event.workflow in the github context.

[ianlewis]

Reopening because we can't rely on workflow in the event payload as it's not present for all event types.
https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads

We'll need to figure out a different way to get the path to the user workflow. We can't rely on github.workflow because that's the workflow name if present, or a path to the workflow if not. While we always want a path to the workflow file.

The only thing I can thing of right now is checking out the user repository and looking for the github.workflow name in the workflow yaml files.

i.e.

if github.workflow is a path:
  use github.workflow as the entrypoint
else
  check out the user repository
  search all workflow yaml files for the workflow name in github.workflow

I'm not really sure that the workflow name even uniquely identifies the workflow being executed.

[ianlewis]

I created a pending topic on github.community to see if there is a way to reliably get the workflow path but I wonder if there aren't other avenues to submit feature requests.

[ianlewis]

In testing the workflow names can be the same for multiple workflows in the same repo so the workflow name by itself won't uniquely identify the workflow being run.

[ianlewis]

It seems that you can query the action run via Github with the run ID and get the workflow path from there.
https://github.com/check-spelling/check-spelling/blob/c35bc3130c33b27843dd0b0f36be8f1d00b6d126/unknown-words.sh#L279-L292

get_workflow_path() {
  action_run=$(mktemp_json)
  if call_curl \
    "$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID" > "$action_run"; then
    workflow_url=$(jq -r '.workflow_url // empty' "$action_run")
    if [ -n "$workflow_url" ]; then
      workflow_json=$(mktemp_json)
      if call_curl \
        "$workflow_url" > "$workflow_json"; then
        jq -r .path "$workflow_json"

via:
https://github.community/t/getting-the-path-to-user-workflow-yaml-from-reusable-workflow/250514

[ianlewis]

The relevant docs for the API endpoints are here
https://docs.github.com/en/rest/actions/workflow-runs#get-a-workflow-run
https://docs.github.com/en/rest/actions/workflows#get-a-workflow

Not sure yet how authentication with the API would work since I'm pretty sure you need some kind of auth or permissions to read them.

[joshuagl]

Not sure yet how authentication with the API would work since I'm pretty sure you need some kind of auth or permissions to read them.

GitHub Actions have GITHUB_TOKEN that can be used to make authenticated API calls: https://docs.github.com/en/actions/security-guides/automatic-token-authentication

[laurentsimon]

neat solution! You can use the gh CLI to play with it too (set GH_TOKEN=THE_TOKEN to make it work non-interactively)

[ianlewis]

Yeah, I've since written something and got it working. It requires adding action scope to the workflow but otherwise seems to work ok. The token is also present in the github context so that's the one I'm actually using.
main...ianlewis:workflow-path

I don't really like where the API is going adding parameters to functions and such so I'm trying a refactor in #47 which should hopefully be a bit easier to work with and not create lots of backwards incompatibilities over time. It should also address some of the thoughts @laurentsimon had on #13. I'll try to add more info to the PR there to make it more clear how it's supposed to work before un-drafting it, but feel free to comment early if you have thoughts.