Add JOB_ env vars

[jenseng]

Add env vars for top-level job context primitives, i.e.

job.check_run_id => $JOB_CHECK_RUN_ID
job.status => $JOB_STATUS

References

• Expose GITHUB_JOB_ID as an environment variable #324
• https://github.com/orgs/community/discussions/129314
• https://github.com/orgs/community/discussions/8945#discussioncomment-14376552

[Copilot]

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 IEnvironmentContextData interface on JobContext class
• 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

[Copilot]

Implicit conversion from StringContextData to string may not work as expected. Use value.ToString() to explicitly convert the value to a string.

Suggested change

	yield return new KeyValuePair<string, string>($"JOB_{data.Key.ToUpperInvariant()}", value);
	yield return new KeyValuePair<string, string>($"JOB_{data.Key.ToUpperInvariant()}", value.ToString());

[qoomon]

I would go for a GITHUB_JOB_ prefix instead of just JOB_ to make it more consistent to other environment variables and to point out that these variables are github context variables.

[jenseng]

That's not a bad idea, I'm curious to see what the maintainers think. I had originally considered that, but:

• It makes it less consistent with how other context -> env vars work, i.e. github. -> GITHUB_ and runner. -> RUNNER_
• There's potentially a risk of collisions if any github.job_... fields are added in the future, since those would also have a GITHUB_JOB_ prefix

Personally my preference would have been to name the context field github.job_id, in which case the env var could just be GITHUB_JOB_ID, but I think that ship has sailed 🫤

cc @ericsciple

[qoomon]

@jenseng I think you are right your name pattern makes sense then

[alexevanczuk]

Hey @jenseng wondering if you're still hoping to get this merged 🙏🏼 excited about it!

[jenseng]

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🤞