Actions needs a better way to specify env variables once for reuse across multiple workflows

[aep-sunlife]

Select Topic Area

Product Feedback

Body

The current way to declare env variables for reuse across multiple GitHub Actions workflows is not great.

tools.txt:

JAVA_VERSION=21
SHELLCHECK_VERSION=0.10.0
STANK_VERSION=0.0.31
...

build.yml:

---
name: "Build"
on: # yamllint disable-line rule:truthy
  push:
  pull_request:
  schedule:
  # Each day at midnight
  - cron: "0 0 * * *"
  workflow_dispatch:
jobs:
  Build:
    runs-on: "ubuntu-24.04"
    steps:
    - uses: "actions/checkout@v4"
    - run: "cat .github/workflows/tools.txt >> \"$GITHUB_OUTPUT\""
      id: "tools"
    - uses: "actions/setup-java@v4"
      with:
        distribution: "corretto"
        java-version: "${{ steps.tools.outputs.JAVA_VERSION }}"
    - run: "make"

It's worth explaining how this rube goldberg operates.

Each variable desired for reuse across workflows must be written in a generic text file, e.g. tools.txt. Possibly tools.properties, based on the parsing behavior of expressions on GITHUB_OUTPUT.

Unlike a conventional shell script, the value portion of the assignment is processed literally, specifically preserving any quotation marks. There is no validation to warn that extra characters will present downstream. Unknown how any commenting syntax may behave. This is fragile and already makes the case for adopting a standard filename like gha.yaml to configure multi-workflow variables. Making quotes part of the variable's YAML value would make the behavior more intuitive. Or input artifacts should support environment variable generation.

After the variables are defined in a text file, each workflow needs to explicitly append the contents of the text file to another file...

The file has a magic name, populated with a GITHUB_OUTPUT variable.

The user cats, or types, depending on whether they're using UNIX or Windows runners. Or for some fringe custom runner with yet another shell notation (rc? ion? fish? legacy Thompson sh?) they may need to use some other obscure command.

Not portable. Projects that desire to compile or test their GitHub repos against all the three stock GitHub Actions runners for macOS, Windows, and Linux, are likely to break 1-2 of these. I'm not a Windows expert. No idea how the Windows runners handle cat when integrating potentially Command Prompt and PowerShell, especially when cat-friendly environments like WSL, Git Bash, MinGW, msysgit, and/or Cygwin, may be partially in use.

The run step that performs the append must populate an id field with a non-blank value, from which the output map will be referenced later.

To reference a variable, the user performs a dot (.) named parameter query on a steps.<k>.outputs entry, where <k> is the id of the GITHUB_OUTPUT appending command. The reference cannot occur in a step before the append run command, and the append run command cannot occur before the repository is checked out. This likely interacts poorly with certain workflows that need to customize how the repository clones.

The example above appends with ASCII chevron (>>) to GITHUB_OUTPUT, but this file may incidentally contain unwanted data from earlier commands. You probably want a single greater than (>) instead, which is also somewhat more portable beyond POSIX.

The full name of the entry, ${{ steps.<k>.outputs.<j> }} ends up being fairly long. It's not fun to read or write this workflow code. This is the very kind of code you need to establish a primary source of truth for package versions, etc., to be copied and pasted multiple times within a single workflow (curl, then untar, then setup PATH and other environment variables...) I don't have much appetite for this amount of boilerplate and risk, when GitHub Actions has an opportunity to simply read from a standard YAMl file instead.

A shorter query expression like ${{ keys.<j> }} would be much appreciated. Better yet, allow users to generate GitHub Actions env entries across workflows, like ${{ env.<j> }}.

Note that $<j> would be a bad solution, as many non-run fields in workflows reject direct environment variables, such as the java-version field in the popular setup-java workflow. That's also why simply sourcing a tools.sh file in each workflow doesn't work so well.

(Yes, many version numbers can and should move to dedicated provisioning systems such as ASDF .tool-versions. However, ASDF and setup-* don't interact very well for now.)

The situation is so awkward that I'm tempted to use GitHub Actions secrets as the primary source of truth for this purpose. Though that would break IaC.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[aep-sunlife]

There's also:

https://github.com/marketplace/actions/file-reader

https://github.com/marketplace/actions/read-file

$GITHUB_ENV with env.<k> seems more direct than GITHUB_OUTPUT. However, GitHub now blocks NODE_OPTIONS from entering GITHUB_ENV.

This functionality should have been provided by the base service long ago, in a more portable way than cat/type and $GITHUB_ENV/%GITHUB_ENV%/$env:GITHUB_ENV.

Note that a run step that mutates GITHUB_ENV or GITHUB_OUTPUT is likely to misbehave when advanced YAML users attempt to collapse multiple run steps into a single multiline command string.

https://github.blog/changelog/2023-01-10-github-actions-support-for-configuration-variables-in-workflows/

I suppose the specific ask is for configuration variables to automatically load from an IaC file.

It's not a good time to create yet more IaC-unfriendly designs. Sure, every user could register some playbooks and corresponding secrets to manually sync an arbitrary file into the repository configuration variables database. But that's awful.

[aep-sunlife]

None of these methods work for the runs-on job field that specifies the runner operating system name and version.

(Per-repo) configuration variables would work, but an IaC option is still needed. There's currently no way to experiment with different values per branch, like you could with a file checked into version control.