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.
There was a problem hiding this comment.
👋 hey @ericsciple, any updates here?
thinking more about potential conflicts with (existing) JOB_ variables people might set, perhaps this could be done slightly more gradually with a feature flag...
before the feature is enabled, these new variables wouldn't get set. but if someone tries to set one of these reserved variable names (via env or $GITHUB_ENV), actions/runner would emit a warning that this will stop working (e.g. JOB_CHECK_RUN_ID is a reserved variable name, and you will no longer be able to set it as of $DATE. Please switch to a different variable name)
then once the feature flag is enabled, the new variables would get set automatically. then if someone tries to set one of them explicitly, the warning text would be slightly different (e.g. JOB_CHECK_RUN_ID is a reserved variable name, so the value you've set has no effect. Please switch to a different variable name)
that could be more trouble than it's worth though, so perhaps an advance announcement would suffice? 🤷♂️
it could also be good to add telemetry around the env variable names people are setting in their workflows/actions, which would give you better insights into how disruptive these kinds of changes might be
|
Will the variables be available in the hooks (ACTIONS_RUNNER_HOOK_JOB_STARTED and ACTIONS_RUNNER_HOOK_JOB_COMPLETED)? |
Yes, those hooks are implemented as steps internally, and all steps will have access to these context variables (just like the existing |
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