-
Notifications
You must be signed in to change notification settings - Fork 271
Description
I encountered an issue while setting up shared composite actions for our teams to easily use Trivy in their workflows. Specifically, the problem arises from how the Trivy action uses >> $GITHUB_ENV
to process inputs and make them available to subsequent steps.
- name: Set Trivy environment variables
shell: bash
run: |
# Note: There is currently no way to distinguish between undefined variables and empty strings in GitHub Actions.
# This limitation affects how we handle default values and empty inputs.
# For more information, see: https://github.com/actions/runner/issues/924
set_env_var_if_provided() {
local var_name="$1"
local input_value="$2"
local default_value="$3"
if [ ! -z "$input_value" ] && [ "$input_value" != "$default_value" ]; then
echo "$var_name=$input_value" >> $GITHUB_ENV
fi
}
Expected Behavior:
The Trivy action documentation suggests running the action multiple times in sequence, for example, to generate different outputs (e.g., SBOM, SARIF, Markdown) or to fail the build only for high-severity vulnerabilities. Each step should be able to set its own input variables.
Actual Behavior:
In practice, it looks like inputs can only be set once per job and cannot be overwritten by subsequent steps. For example, the first step in the workflow sets the output format (e.g., github), but later steps ignore their own inputs and continue using the values from the first step. This seems related to this GitHub Actions runner issue.
Workaround:
A possible workaround is to avoid using action inputs and rely on env:
variables prefixed with TRIVY_
across steps. However, this has significant drawbacks:
- Input precedence violation: Inputs should typically have higher precedence than environment variables, but this approach flips that assumption.
(- Question?: Passing sensitive data (like tokens) viaenv:
could lead to leaks, as environment variables might not be handled as securely as inputs)
Request:
Is there a better way to handle action inputs to avoid this limitation? It would ensure consistent behavior across steps without needing hacky workarounds