Describe $RUNNER_OS/$RUNNER_TEMP/$RUNNER_TOOL_CACHE environment variables

[jmarshall]

Why:

Closes #6127.

What's being changed:

As noted in #6127, several $RUNNER_xyz environment variables are set up by runners corresponding to ${{ runner.xyz }} context properties. A total of seven RUNNER_* environment variables are currently set in job steps, and it is unclear which are intended to be used and are supported for use by workflow steps. There are three corresponding runner context properties that are documented in “Context and expression syntax for GitHub Actions”, so this PR adds the environment variables corresponding to these three to the “Default environment variables” list:

Environment variable	Description
RUNNER_OS	The operating system of the runner executing the job. Possible values are Linux, Windows, or macOS.
RUNNER_TEMP	The path of the temporary directory for the runner. This directory is guaranteed to be empty at the start of each job, even on self-hosted runners.
RUNNER_TOOL_CACHE	The path of the directory containing some of the preinstalled tools for [GitHub]-hosted runners. For more information, see "Specifications for [GitHub]-hosted runners".

(The tool_cache property value is not documented as being used for GitHub AE, so this PR just leaves $RUNNER_TOOL_CACHE unlisted and undocumented in this case.)

In considering merging this, it would be prudent for GitHub staff to confirm exactly which of these environment variables are intended to be supported for use in workflow steps; in particular, to confirm whether exactly these three are supported as environment variables, similarly to their context property equivalents.

(On #6127 it was suggested that I might attempt to confirm which are supported by contacting GitHub Support. However there is little point in a non-GitHub-employee such as myself doing that, as whoever took responsibility for merging this would need to confirm directly with other GitHub employees (in engineering or support) that the information so obtained was accurate.)

Check off the following:

• I have reviewed my changes in staging (look for the deploy-to-heroku link in your pull request, then click View deployment).
• For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

• This pull request impacts the contribution experience
  • I have added the 'writer impact' label
  • I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[janiceilene]

👋 @jmarshall We cannot accept this PR until you've verified with support which environment variables should be documented. After you get that information from the support team please feel free to open a new issue with that information.

Thanks for your interest in improving the GitHub docs!

[jmarshall]

This repository's CONTRIBUTING.md says

We (usually the docs team, but sometimes GitHub product managers, engineers, or supportocats too!) review every single PR.

This implies that sometimes the GitHub Docs team brings PRs to the attention of their GitHub colleagues in the relevant part of Engineering who will review them directly. That would be a much more efficient way to verify which of these environment variables are supported than for me to compose the question a third time in such detail that Support sees its meaning, routes the question to the right people, and replies in a reasonable timeframe. But, as noted above, even if that happened it would be pointless because you would have no reason to believe what I, a non-GitHub-employee, reported — so the Docs team would have to verify it directly with Engineering anyway.

I notice that in e.g. #3060 (comment), #3788 (review), #4945 (comment), #5359 (comment), and #6615 (comment) the Docs team have themselves consulted their colleagues elsewhere within GitHub to directly verify aspects of these other outsiders' PRs.

Is there a reason why this PR is being treated differently? Thanks.

[janderssonse]

Following. The reason given for closing this does not make sense at all IMHO. It basically says that PR's for GH Docs should go to https://support.github.com/contact first?

[janiceilene]

👋 @jmarshall I’ve spoken with the team and we've decided to reopen this PR. I apologize for closing this PR prematurely. Thank you for taking the time to voice your concerns with our process so that we can continue to improve.

Please note that we’ll still need to validate with the engineering team and don’t know when they’ll have the bandwidth to prioritize. We appreciate your patience.

[martin389]

Changes in this PR

(The links below will stop working after merge)

Article in staging	Changes
“Default environment variables”	Adds entries to table for RUNNER_OS, RUNNER_TEMP, and RUNNER_TOOL_CACHE
"Context and expression syntax for GitHub Actions"	Moved descriptions into reusables for consistency.

[martin389]

(Closing and reopening this PR for CI purposes)

[martin389]

Checking questions with support.

[martin389]

Sorry about the delay here, following up 👍

[martin389]

Received confirmation that these environment variables are supported: RUNNER_OS, RUNNER_TEMP, and RUNNER_TOOL_CACHE 👍

[github-actions]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡

[martin389]

Changes are now live:

Published article	Changes
“Default environment variables”	Adds entries to table for RUNNER_OS, RUNNER_TEMP, and RUNNER_TOOL_CACHE
"Context and expression syntax for GitHub Actions"	Moved descriptions into reusables for consistency.