fix: write GH_HOST to GITHUB_ENV instead of GITHUB_OUTPUT#22974
Merged
Conversation
The ghes-host-config step wrote GH_HOST to $GITHUB_OUTPUT, but the output was only consumed by user-provided typed steps that the compiler explicitly injected it into. Generated steps (e.g. Process Safe Outputs) never received GH_HOST, and workflows without user-provided steps had the step as a complete no-op. Fix: write to $GITHUB_ENV so that ALL subsequent steps in the job automatically inherit GH_HOST. This matches how the main agent job handles it via configure_gh_for_ghe.sh. The per-step injection code in compiler_jobs.go and compiler_safe_outputs_job.go is removed since GITHUB_ENV makes it redundant. The Copilot installer's step-level GH_HOST: github.com override still takes precedence (step env > GITHUB_ENV). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes GHES/GHEC host propagation in compiled workflows by exporting GH_HOST via $GITHUB_ENV (job environment) rather than $GITHUB_OUTPUT (step output), ensuring both generated and user-provided steps receive GH_HOST without per-step injection.
Changes:
- Update the generated
ghes-host-configstep to writeGH_HOSTto$GITHUB_ENV. - Remove redundant per-step
GH_HOSTenv injection from compiler paths that previously depended on${{ steps.ghes-host-config.outputs.GH_HOST }}. - Recompile affected workflow lock files to reflect the new propagation mechanism.
Reviewed changes
Copilot reviewed 177 out of 177 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/workflow/ghes_host_step.go | Switches GH_HOST export from $GITHUB_OUTPUT to $GITHUB_ENV. |
| pkg/workflow/compiler_jobs.go | Removes redundant per-step GH_HOST injection for custom (frontmatter) jobs. |
| pkg/workflow/compiler_safe_outputs_job.go | Removes redundant per-step GH_HOST injection for user-provided safe-outputs steps. |
| pkg/workflow/ghes_host_step_test.go | Updates assertions to validate $GITHUB_ENV usage instead of $GITHUB_OUTPUT. |
| .github/workflows/*.lock.yml | Recompiled lock workflows reflecting $GITHUB_ENV export and removal of per-step injected GH_HOST. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This was referenced Mar 25, 2026
This was referenced Mar 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #22957
Problem
The
ghes-host-configstep in compiled workflows wroteGH_HOSTto$GITHUB_OUTPUT, but the output was only consumed by user-provided typed steps that the compiler explicitly injected${{ steps.ghes-host-config.outputs.GH_HOST }}into. This had two issues:GH_HOST— they weren't typed steps with explicit injectionFix
Write
GH_HOSTto$GITHUB_ENVinstead of$GITHUB_OUTPUT. This makesGH_HOSTautomatically available to ALL subsequent steps in the job — both user-provided and generated — without needing explicit per-step injection.This matches how the main agent job already handles GH_HOST via
configure_gh_for_ghe.sh(which writes toGITHUB_ENV).Changes
pkg/workflow/ghes_host_step.go— Write to$GITHUB_ENVinstead of$GITHUB_OUTPUTpkg/workflow/compiler_jobs.go— Remove redundant per-step GH_HOST injection (GITHUB_ENV makes it automatic)pkg/workflow/compiler_safe_outputs_job.go— Remove redundant per-step GH_HOST injectionpkg/workflow/ghes_host_step_test.go— Update assertions.lock.ymlfilesNot a bug: GH_HOST: github.com in Copilot installer
The issue also mentions
GH_HOST: github.comhardcoded in the Copilot CLI install step. This is intentional — the Copilot CLI binary is always downloaded from github.com regardless of GHES host. The step-level env override only affects that install step and still takes precedence overGITHUB_ENV.