You now (June 2022) have an alternative:
You could try and take advantage of a new feature (June 2022)
Workflows triggered by workflow_dispatch
and workflow_call
can now access their inputs using the inputs
context.
Previously workflow_dispatch
inputs were in the event
payload.
This made it difficult for workflow authors who wanted to have one workflow that was both reusable and manually triggered.
Now a workflow author can write a single workflow triggered by workflow_dispatch
and workflow_call
and use the inputs
context to access the input values.
For workflows triggered by workflow_dispatch
, inputs are still available in the github.event.inputs
context to maintain compatibility.
Using the inputs context in GitHub Actions.
In your case:
jobs:
printInputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Log level: ${{ inputs.logLevel }}"
echo "Tags: ${{ inputs.tags }}"
Is it possible to avoid printing the inputs in the logs?
To avoid printing the inputs in GitHub Actions logs, you can still access the inputs but manipulate them in a way that prevents them from being directly output to the logs.
FOr instance, you can set the inputs as environment variables and then use them in your scripts. Environment variables are not automatically printed in logs.
GitHub Actions has a feature to mask values in logs. You can use the ::add-mask::
command to mask a value. Once a value is masked, it will be replaced with ***
in the logs.
jobs:
processInputs:
runs-on: ubuntu-latest
steps:
- name: Set up environment variables
run: |
echo "LOG_LEVEL=${{ inputs.logLevel }}" >> $GITHUB_ENV
echo "TAGS=${{ inputs.tags }}" >> $GITHUB_ENV
- name: Run script with inputs
run: |
./your-script.sh
env:
LOG_LEVEL: ${{ secrets.LOG_LEVEL }}
TAGS: ${{ secrets.TAGS }}
Here, the inputs are set as environment variables. These variables are then passed to a script (your-script.sh
) which can use these values internally.
If necessary, you can mask sensitive inputs using ::add-mask::
.
Another option: You can pass the inputs to a script and process them inside the script. That way, the actual values will not be directly printed in the logs.