Add JOB_ env vars#4053
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for exposing job context primitives as environment variables by implementing the IEnvironmentContextData interface on JobContext. The implementation allows job.check_run_id and job.status to be accessible as $JOB_CHECK_RUN_ID and $JOB_STATUS environment variables respectively.
- Implements
IEnvironmentContextDatainterface onJobContextclass - Adds
GetRuntimeEnvironmentVariables()method to expose job context data as environment variables - Includes comprehensive unit tests to verify the environment variable generation functionality
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Runner.Worker/JobContext.cs | Implements IEnvironmentContextData interface and adds method to convert job context properties to environment variables |
| src/Test/L0/Worker/JobContextL0.cs | Adds unit tests to verify correct environment variable generation from job context data |
|
Hey @jenseng wondering if you're still hoping to get this merged 🙏🏼 excited about it! |
@alexevanczuk absolutely! Just waiting for the GitHub folks to review it🤞 |
|
@TingluoHuang @ericsciple @pje I've noticed you've all created or reviewed PRs related to this file. Is this something you'd be able to take a look at and help merge? It would help folks use this new excellent flag in a way that is conventional with how they are checking other similar properties (using environment variables). Would be a huge boon for our ability to deep link into jobs and the change looks smallish so would love it if you could take a look and help get this merged if possible 🙏🏼 |
|
? |
Add env vars for top-level primitives in job context job.check_run_id => JOB_CHECK_RUN_ID job.status => JOB_STATUS job.workflow_ref => JOB_WORKFLOW_REF job.workflow_sha => JOB_WORKFLOW_SHA job.workflow_repository => JOB_WORKFLOW_REPOSITORY job.workflow_file_path => JOB_WORKFLOW_FILE_PATH
03d3181 to
1e51143
Compare
|
rebased and updated to account for #4335 |
| } | ||
| } | ||
|
|
||
| private readonly HashSet<string> _contextEnvAllowlist = new(StringComparer.OrdinalIgnoreCase) |
There was a problem hiding this comment.
Thanks @jenseng! I want to collect some more thoughts internally.
I'm thinking about namespace conflict (if customers already use JOB_ variables). I'm waiting on one of the individuals to get back from vacation.
There was a problem hiding this comment.
Yeah that's a fair point and definitely worth considering. Another possibility could be to have a GITHUB_JOB_ prefix, though that has some downsides of its own (i.e. inconsistent with how runner/github variables are named, and it could conflict with future github.job_... variables)
There was a problem hiding this comment.
Good callout on RUNNER_ variables 👍. That naming precedent helps.
We can likely add JOB_ but may need some advance announcement before it rolls out. I will discuss more with folks internally.
Add env vars for top-level job context primitives, i.e.
job.check_run_id=>$JOB_CHECK_RUN_IDjob.status=>$JOB_STATUSjob.workflow_ref=>$JOB_WORKFLOW_REFjob.workflow_sha=>$JOB_WORKFLOW_SHAjob.workflow_repository=>$JOB_WORKFLOW_REPOSITORYjob.workflow_file_path=>$JOB_WORKFLOW_FILE_PATHReferences