[feature] Add allowlisted secret export for notebook workflow runs

[mbruns91]

Motivation

Some downstream repositories need selected repository secrets available while notebooks are executed in CI, for example when notebooks require service tokens or API keys. The existing notebook workflow did not provide a controlled way to pass such secrets into the notebook runtime.

Some discussion on this topic can be found in #165.

Summary

This PR adds an explicit, allowlist-based mechanism for exporting selected inherited secrets as environment variables before notebook execution. The implementation keeps secret handling outside the build-notebooks action and limits the notebook runtime to only the requested secret values.

Changes / Added Features

• Added a new export-secret-env composite action.
• Added .support/export_secret_env.py for parsing and exporting selected secrets.
• Added notebooks-secret-env-map to the reusable push-pull.yml workflow.
• Supports both SECRET_NAME and ENV_VAR_NAME=SECRET_NAME mapping entries.
• Supports multiline secret values via GitHub’s $GITHUB_ENV multiline syntax.
• Validates environment variable names, secret names, duplicate env mappings, and missing requested secrets.
• Documented the new action in the README.

Intended Use

Downstream repositories can opt in from the reusable workflow call by providing something along the lines

with:
  notebooks-secret-env-map: |
    SECRET_NAME
    ENV_VAR_NAME=SECRET_NAME

where

• SECRET_NAME exports a secret under the same environment variable name.
• ENV_VAR_NAME=SECRET_NAME exports a secret under a different environment variable name.

Security Implications

Secrets are only exported when explicitly requested by name. The notebook runtime receives only the selected environment variables, not the full inherited secrets object.
This does not create a hard security boundary against trusted workflow code with access to repository secrets. It is intended to reduce accidental exposure, avoid broad secret discovery during notebook execution, and keep secret handling concentrated in one small export step.

[Copilot]

Pull request overview

Adds a controlled, allowlist-based mechanism to export selected inherited GitHub Actions secrets as environment variables for notebook execution in CI, keeping the full secrets object scoped to a single export step.

Changes:

• Introduces a new export-secret-env composite action to export selected secrets into $GITHUB_ENV.
• Adds .support/export_secret_env.py to parse/validate mappings and write multiline-safe env exports with masking.
• Extends the reusable push-pull.yml workflow with a notebooks-secret-env-map input and wires it into the notebooks job; documents the feature in the README.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
export-secret-env/action.yml	New composite action wrapper that runs the secret-export helper script.
.support/export_secret_env.py	Implements parsing/validation, secret lookup, masking, and $GITHUB_ENV export.
.github/workflows/push-pull.yml	Adds workflow-call input and runs export step before build-notebooks.
README.md	Documents the new export-secret-env action.
.gitignore	Adds ignores for editor/tool artifacts.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[liamhuber]

Yeah, lgtm. I think we should use this as a rather strong motivating example to restructure the org so not all members get defaulted to write privileges.

From a practical standpoint, I think you should test it out before merging it. This is, unfortunately, still very much a by-hand process where you go to some use-case repo and target pyiron/actions/.github/workflows/push-pull.yml@notebook-envvars -- as soon as it's a branch available here, consumer repos are free to target it!

The catch with that is that you'll need to run the re-naming script, otherwise internal calls like uses: pyiron/actions/export-secret-env@actions-4.0.13 aren't going to work because export-secret-env doesn't exist on export-secret-env.

Once you've renamed it to match the branch, and verified that it works by targeting the branch, I recommend running the rename script one final time with the intended release tag actions-4.1.0. Then once it's merged immediately make that release, and all the code at HEAD at time of release will already correctly point to the release tag.

The way I've been doing it is to give my branches release-tag names to start with. It accomplishes the same thing, but then you just rename it once and any downstream consumer you used to test it is already preemptively pointing at the latest release!

Anyway, assuming manual testing doesn't uncover any bugs, I'm happy with what's here.

[mbruns91]

Ok, I did it (sorry, I wasn't sure what to target at first...).

Tested here. I tried both syntaxes (only specifying SECRET_NAME, giving the envvar the same name, as well as ENVVAR_NAME=SECRET_NAME to give it another name). As far as I can tell, everything seems to work as intended.