For some reason, the workflow_dispatch action is somewhat of a second-class citizen, and does not receive a lot of the "safe by default" behavior that other action types do.
For example, there's not clear or obvious way to keep inputs secret & masked from the logs. GitHub's add-mask functionality doesn't work because the echo statement required to create the mask logs the value (see this demo repo run).
If these inputs were automatically injected as environment variables like the documentation suggest it does with $INPUT_, we wouldn't have to worry about the values being logged, but as of right now, workflow_dispatch actions do not receive that behavior.
The common workaround seems to be to parse out the inputs from the GITHUB_EVENT JSON and put those into an env var which then doesn't get logged. Something like:
jobs:
test-secret:
runs-on: ubuntu-latest
steps:
- name: Create secret environment variables from inputs
run: |
SUPER_SECRET=$(jq -r '.inputs.super_secret' $GITHUB_EVENT_PATH)
echo ::add-mask::$SUPER_SECRET
echo SUPER_SECRET="$SUPER_SECRET" >> $GITHUB_ENV
- name: Now, I can safely use input via environment variable
run: echo "$SUPER_SECRET" # the output from this command will be "echo ***"
This is suggested a few times here, here and here.
Instead, I stumbled on this GitHub Community Action which goes a step further and uses a node script to access GitHub action's core's setSecret method. This felt like a less hacky way to go about protecting the sensitive information. You can see the results of using it in this demo repo.
For some reason, the
workflow_dispatchaction is somewhat of a second-class citizen, and does not receive a lot of the "safe by default" behavior that other action types do.For example, there's not clear or obvious way to keep inputs secret & masked from the logs. GitHub's
add-maskfunctionality doesn't work because the echo statement required to create the mask logs the value (see this demo repo run).If these inputs were automatically injected as environment variables like the documentation suggest it does with
$INPUT_, we wouldn't have to worry about the values being logged, but as of right now,workflow_dispatchactions do not receive that behavior.The common workaround seems to be to parse out the inputs from the
GITHUB_EVENTJSON and put those into an env var which then doesn't get logged. Something like:This is suggested a few times here, here and here.
Instead, I stumbled on this GitHub Community Action which goes a step further and uses a node script to access GitHub action's core's
setSecretmethod. This felt like a less hacky way to go about protecting the sensitive information. You can see the results of using it in this demo repo.