Use workflow filename (not display name) as caller workflow ID#19408
Use workflow filename (not display name) as caller workflow ID#19408
Conversation
…kflow name - Change GH_AW_CALLER_WORKFLOW_ID to use github.workflow_ref instead of github.repository/github.workflow (which used the display name) - Add parseCallerWorkflowId() helper to generate_footer.cjs that extracts owner/repo/workflow-id from the workflow_ref format - Update all 5 JS handlers to parse GH_AW_CALLER_WORKFLOW_ID through the helper - Recompile all 165 workflow lock files Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot the compiler should compute the filename without extension and use it instead of github.workflow_ref |
… of workflow_ref
The compiler now embeds the workflow ID (filename without extension) as a
compile-time constant: GH_AW_CALLER_WORKFLOW_ID = "${{ github.repository }}/workflow-id"
This removes the need for the JS parseCallerWorkflowId() helper entirely.
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Done in 6320298. The compiler now embeds the workflow ID (filename without extension) as a compile-time constant: Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
There was a problem hiding this comment.
Pull request overview
Updates GH_AW_CALLER_WORKFLOW_ID to use a stable workflow identifier derived from the workflow filename (instead of the mutable name:/github.workflow display name), so markers used by close-older-* don’t change when workflows are renamed.
Changes:
- Update the Go compiler to emit
GH_AW_CALLER_WORKFLOW_IDas"${{ github.repository }}/<workflow-id>", where<workflow-id>is the compiled workflow ID (filename without extension). - Adjust compiler tests to match the new
GH_AW_CALLER_WORKFLOW_IDformat. - Refresh JS marker documentation/comments and recompile generated workflow lock files to propagate the new env var value.
Reviewed changes
Copilot reviewed 163 out of 163 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/workflow/compiler_safe_outputs_job.go | Changes how GH_AW_CALLER_WORKFLOW_ID is constructed in the compiled safe-outputs job env. |
| pkg/workflow/compiler_safe_outputs_job_test.go | Updates expectations for GH_AW_CALLER_WORKFLOW_ID in unit tests. |
| actions/setup/js/generate_footer.cjs | Updates documentation for workflow-call-id marker semantics/examples. |
| actions/setup/js/create_issue.cjs | Updates comments describing GH_AW_CALLER_WORKFLOW_ID usage in issue creation + history link generation. |
| actions/setup/js/create_discussion.cjs | Updates comments describing GH_AW_CALLER_WORKFLOW_ID usage in discussion creation + history link generation. |
| .github/workflows/*.lock.yml | Recompiled generated workflows to use the new GH_AW_CALLER_WORKFLOW_ID expression/value across workflows. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // GH_AW_CALLER_WORKFLOW_ID is set at compile time to `github.repository/<workflow-id>`. | ||
| // When multiple workflows call the same reusable workflow via workflow_call they all | ||
| // share the same GH_AW_WORKFLOW_ID. We embed a separate gh-aw-workflow-call-id marker | ||
| // with the caller's identity so close-older-discussions can distinguish callers precisely. |
There was a problem hiding this comment.
The comment claims GH_AW_CALLER_WORKFLOW_ID is "set at compile time to github.repository/<workflow-id>", but ${{ github.repository }} is evaluated at runtime (the compiled workflow just contains the expression). With the updated compiler logic, this variable may also no longer identify the caller workflow for workflow_call reuse, so the rationale here can be inaccurate. Please adjust the comment to describe the actual behavior/guarantees.
| // Set GH_AW_CALLER_WORKFLOW_ID to uniquely identify the calling workflow at runtime. | ||
| // When a reusable workflow is called via workflow_call, multiple callers share the | ||
| // same GH_AW_WORKFLOW_ID (derived from the reusable file). This separate runtime | ||
| // value uniquely identifies each caller and is used as the issue/discussion marker | ||
| // for close-older-issues, preventing cross-caller false closes. | ||
| envVars["GH_AW_CALLER_WORKFLOW_ID"] = `"${{ github.repository }}/${{ github.workflow }}"` | ||
| // same GH_AW_WORKFLOW_ID (derived from the reusable file). This separate value | ||
| // combines the runtime repository (to identify the caller repo) with the compile-time | ||
| // workflow ID (filename without extension), producing a stable "owner/repo/workflow-id" | ||
| // form used for close-older-issues disambiguation. | ||
| envVars["GH_AW_CALLER_WORKFLOW_ID"] = fmt.Sprintf(`"${{ github.repository }}/%s"`, workflowID) |
There was a problem hiding this comment.
GH_AW_CALLER_WORKFLOW_ID is now derived from the compiled workflowID, which means for reusable workflows (on: workflow_call) it identifies the callee workflow file rather than the caller. This contradicts the surrounding comment about disambiguating multiple callers of the same reusable workflow and will cause close-older-issues/discussions to treat different callers as the same (e.g., a reusable workflow called from multiple workflows in the same repo will emit the same owner/repo/<reusable-id> marker). Consider keeping a caller-derived runtime value for workflow_call (or passing the caller workflow-id into the reusable via workflow_call inputs) and updating the logic/comments/tests accordingly.
| // GH_AW_CALLER_WORKFLOW_ID is set at compile time to `github.repository/<workflow-id>`. | ||
| // When multiple workflows call the same reusable workflow via workflow_call they all | ||
| // share the same GH_AW_WORKFLOW_ID. We embed a separate gh-aw-workflow-call-id marker | ||
| // with the caller's identity so close-older-issues can distinguish callers precisely. |
There was a problem hiding this comment.
The comment says GH_AW_CALLER_WORKFLOW_ID is "set at compile time to github.repository/<workflow-id>", but the value is actually provided at runtime via a GitHub Actions expression (${{ github.repository }}) embedded into the compiled workflow. Also, with the new compiler behavior this env var may no longer represent the caller workflow in workflow_call scenarios—so this explanation can become misleading. Please update the wording to reflect how the value is produced and what it represents.
GH_AW_CALLER_WORKFLOW_IDwas built fromgithub.repository/github.workflow, wheregithub.workflowis the YAMLname:field — a mutable display name. This makes the marker unstable and breaksclose-older-issuesdisambiguation when workflows are renamed.Changes
Go compiler (
compiler_safe_outputs_job.go): Changed env var value to"${{ github.repository }}/<workflow-id>"where<workflow-id>is the workflow filename without extension, computed at compile time viaGetWorkflowIDFromPath. For example,ai-moderator.mdproduces"${{ github.repository }}/ai-moderator".JS handlers (
create_issue,create_discussion,update_issue,add_comment,update_pull_request): No parsing needed — handlers readGH_AW_CALLER_WORKFLOW_IDdirectly since the value is already in the stableowner/repo/workflow-idform at runtime.All 165 lock files recompiled to pick up the new expression.
Original prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.