Which workflow did that run execute?

A client asks which automation ran, and the room answers with a green check. Tonight, three proofs, in a repository the agency or the client can open. Name the workflow that run executed: the run id, the workflow id, the name, the path, and the event. Show a different run whose path or workflow id is not this one. Show another client's repository that does not list this run. If any of the three needs the person who copied the YAML and then left, you have not named the workflow. You have a check and a guess.

This is the workflow file one run recorded. It is not the action that file fetched. Name the action the workflow runs is the uses line and the ref: a tag, a branch, or a full commit SHA. A pinned action can sit in the wrong file, and the right file can still float a tag. It is not the machine. Which runner did that job use? is the label and the runner that took the job. A label is not a path. It is not where the change landed. Which environment got that change? is the environment name and the artifact that arrived there. An environment can be production while the run's path is a file you have not opened. It is not the review that blocked a merge. Which review blocked that merge? is a review on a pull request. A review is not a workflow id. It is not the cache the job restored. Which cache did that job restore? is a cache record. A cache key is not a YAML path.

None of what follows is a finding that this client's workflows are unsafe, and none of it is legal advice. The fields below are GitHub's current description of a workflow run, and the two examples on that page do not agree with each other. The counts below that are a 2022 study of public repositories cloned on one day, not a private repository in 2026. A percentage of public YAML files is not the path on the run you opened tonight. A green check is not a file name.

GitHub's list example and GitHub's get example print the same run id and not the same branch. Both print id 30433642, name Build, workflow_id 159038, run_number 562, check_suite_id 42, path .github/workflows/build.yml@main, event push, status queued, conclusion null, and display_title Update README.md. The list example's head_branch is master. The get example's head_branch is main. master is not main. Do not merge the two examples into one branch because the id matches. 30433642 is not 159038. 159038 is not 562. 562 is not 42. 42 on a check suite is not a count of proofs. name is Build. 5 characters. display_title is Update README.md. 16 characters. 5 is not 16. The path string is 32 characters and ends in @main. On the list example, @main is not the head_branch master. A suffix inside a path is not the branch field. created_at, updated_at, and run_started_at are all 2020-01-22T19:33:08Z. Three fields, one timestamp. Equality is not three events. run_attempt is 1. actor and triggering_actor both print login octocat and id 1. Two objects can print the same id and still be two objects. pull_requests is an empty array. Empty is not a pull request number. The page's version header in the note is 2026-03-10. 2026-03-10 is not 2020-01-22 (GitHub, REST API endpoints for workflow runs).

The filter that lists runs is a different list from the fields on one run. The status parameter says it returns runs with the check run status or conclusion you specify, and that a conclusion can be success or a status can be in_progress. Only GitHub Actions can set a status of waiting, pending, or requested. The values it then names are completed, action_required, cancelled, failure, neutral, skipped, stale, success, timed_out, in_progress, queued, requested, waiting, and pending. 14 names. The sentence has already told you the list mixes conclusions and statuses. Do not call all 14 of them statuses, and do not call all 14 of them conclusions. queued is in that list. The sample's status is queued, and its conclusion is null. null is not success, and queued is not completed. per_page defaults to 30 and the maximum is 100. The same page says the list returns up to 1,000 results for a search on actor, branch, check_suite_id, created, event, head_sha, or status. 30 is not 100. 100 is not 1,000. 1,000 is not the sample's run_number 562.

The get example adds referenced_workflows, and that array is not the path of the run. The array contains three objects. The first path is octocat/Hello-World/.github/workflows/deploy.yml@main, with sha 86e8bc9ecf7d38b1ed2d2cfb8eb87ba9b35b01db and ref refs/heads/main. The second path is octo-org/octo-repo/.github/workflows/report.yml@v2, with ref refs/tags/v2. Neither path is .github/workflows/build.yml@main. deploy.yml is not build.yml. report.yml is not build.yml. The first referenced sha is not the run's head_sha acb5820ced9479c074f688cc328bf03f341a511d. A workflow a run calls is not the workflow the run itself is. The page also says you can replace workflow_id with the workflow file name when you list runs for one workflow, for example main.yaml. main.yaml is not build.yml. An example of a file name you may pass is not the path the sample stored.

The study people quote when they want a share of repositories that use Actions counted files, not this run. Alexandre Decan, Tom Mens, Pooya Rostami Mazrae, and Mehdi Golzadeh, at the University of Mons, cloned repositories on 2022-01-24. They kept repositories with at least 100 commits and 100 stars and obtained 69,147 repositories, containing 70,278 workflows, 108,500 jobs, and 576,352 steps. 100 commits is not 100 stars, and neither 100 is the API's per_page maximum, even though the numeral matches. 69,147 is not 70,278. 70,278 is not 108,500. 108,500 is not 576,352. The abstract says a dataset comprising 68K repositories, of which 43.9% are using GitHub Actions workflows. The body says 29,778 of the 69,147 contain at least one workflow file, and it calls that 43.9%. 29,778 divided by 69,147 is 0.431, which rounds to 43.1%, not 43.9%. Do not replace either printed figure with the quotient, and do not replace 68K with 69,147. 2022-01-24 is not the sample run's 2020-01-22 (Decan, Mens, Rostami Mazrae, and Golzadeh, On the Use of GitHub Actions in Software Development Repositories).

The averages and the event table do not share one denominator. They say 70,278 workflows in 29,778 repositories is an average of 2.4 workflows per repository. 70,278 divided by 29,778 is 2.36, which rounds to 2.4. Nearly half, 49.3%, defined a single workflow, and the remaining 50.7% defined more. 49.3 plus 50.7 is 100. Inside the remainder they print two workflows at 22.6%, three at 11.7%, and four at 6.3%. 22.6 plus 11.7 plus 6.3 is 40.6, not 50.7. The gap is the repositories they did not put in those three bins, including the dozens they mention with 20 or more workflows. Dozens is their word. Do not replace it with an integer the page does not print. The ten events they list, as a share of workflows, are push 41.8, pull_request 34.1, workflow_dispatch 8.3, schedule 8.1, release 3.0, pull_request_target 1.3, issues 1.0, repository_dispatch 0.7, issue_comment 0.6, and workflow_run 0.4. Those ten sum to 99.3, which is the total the table prints. 99.3 is not 100. push is 41.8% of workflows and 63.4% of repositories. 41.8 is not 63.4. The sample run's event is push. push is not 41.8% of your repository.

Jobs and steps are a second cut, and one printed average does not survive the division. They found 108,500 jobs in 70,278 workflows, and they call that an average of 1.5 jobs per workflow. They also say 77.8% of workflows define a single job and 10.5% define two. 77.8 plus 10.5 is 88.3, not 100. Only 823 jobs, which they call 0.8%, from 254 repositories, reuse another workflow through the uses key. 823 is not 254. 823 divided by 108,500 is 0.0076, which rounds to the 0.8% they print. They found 576,352 steps for 108,500 jobs, and they call that 5.2 steps per job. 576,352 divided by 108,500 is 5.312, which rounds to 5.3, not 5.2. Do not replace the printed 5.2 with 5.3, and do not replace 5.3 with the printed 5.2. The median they print for steps per job is 5. 5 is not 5.2, and 5 is not 5.3. Steps per workflow are printed as 8.2 on average and 5 at the median. 8.2 is not 5.

The step-type table sums, and the sentence beside it does not use the same half. run is 49.9% of steps. uses, split by target, is local path 0.8, Docker image 0.1, same repository 0.2, same owner 0.7, and other repository 48.3. Those six cells sum to 100.0. 100 minus 49.9 is 50.1. The prose says around half of the steps, 51.1%, use an action. 51.1 is not 50.1. Do not average them. The same paragraph says 139,501 distinct commands among the 287,868 steps that define a run key. 287,868 divided by 576,352 is 0.499, which matches the 49.9% cell. It does not match 51.1%. The top actions they list sum to 70.8% of steps, and the total cell prints 70.8. The next sentence says 8 of the top 10 actions are GitHub's own and are used by 71.2% of the steps. 71.2 is not 70.8. 8 is not 10. actions/checkout is 35.5% of steps and 97.8% of repositories. 35.5 is not 97.8, and neither is a workflow id. The language table's counts sum to 69,147, which matches the repository total. JavaScript is 13,542, printed as 19.6% of the dataset. 13,542 divided by 69,147 is 0.196, which rounds to 19.6%. TypeScript is 9.2% of the dataset and 58.5% of TypeScript repositories use a workflow. 9.2 is not 58.5. A language share is not the path on this run.

Do the three proofs on one real run, in the repository that actually holds it. First, the binding. Copy the run id, the workflow id, the name, the path, and the event. If the name is null, write null. Do not infer Build because a sample prints it, and do not infer run 30433642. If the path on the list example and the path on the get example ever disagree, write both and do not pick one. Second, the other workflow. A different run, with a different path or a different workflow id, is not this one. A share of public repositories is not that second run. If you cannot show a run that is not this file, you have a counter, not a record. Third, the other client. A repository that belongs to someone else does not contain this run id. If the only log is a single shared account and you cannot say whose run it is, write that. A tenant you cannot name is the finding. It is not a reason to tell the client the file was build.yml.

Three moves feel like the proof and are a second problem. Renaming the check to the file you wish had run, and then describing the missing path as a cleanup. Quoting 43.9% because it looks precise, while the run you were asked about is one id, and the body that printed 43.9% does not match 29,778 divided by 69,147. Asking a model which workflow ran. The model will pick a plausible file name. It will not open the run. A ref you have not pinned, while the client is arguing about a third-party action, is name the action the workflow runs. Opening that line does not name the workflow id.

The path is ordinary when an operator can open one client's project without opening the next client's project as the way to prove it. Gigbase is a multi-user agency portal: projects, teams, and clients in one workspace. The shape that matters here is one client's project you can point at, distinct from the next client's project. That case is not a workflow ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen shows every client at once and will not name a run, you do not have this proof. You have a directory.

There is a version of this afternoon where the agency should not take the work. The work is not sold under the agency's name. The client asked to meet the builders. The room only has a slide. The buyer only wants a template. Or the buyer wants a legal opinion about a license the file pulled in. A white label software development partner that expects this will have put the run, the workflow id, and the path where the agency can open them without a call to the person who left. One that needs that call is telling you who holds the file. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which repository stores the run, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that 43.9% of anything applies, and they are not 30433642.

The customer a charge names, and the category a moderation call flagged, are different objects: which customer did that charge name? and which category did that call flag?. Do not record either on this page. A customer id is not a workflow id. A category score is not a path.

Before you tell the client which automation ran, do the three proofs and write the file. Name the run, the workflow id, the name, the path, and the event, or write that a field was null. Show a different run that is not that file. Show another client's repository that does not hold it. Do not paste master onto main because one example used each, and do not ask a model which YAML it was. A paper can tell you how public repositories were using Actions on one day in 2022. The binding is the run you can defend.