Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Set env var if it differs from actual value #437

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

david-marconis
Copy link

@david-marconis david-marconis commented Nov 28, 2024

Problem

There is an issue with the current action if you run multiple Trivy actions in a row. It will not respect the inputs as it will not set the env var if the env var if the input value is a different value. However, if the env var already has a different value than the default and you try to set it to a default value, it will not work.

Scenario

Here is a scenario: You first run Trivy scan with sarif format, and then you run with table format:

        - uses: aquasecurity/[email protected]
          with:
            image-ref: node:23.2.0-alpine3.20
            severity: CRITICAL,HIGH
            exit-code: 0
            format: sarif
        - uses: aquasecurity/[email protected]
          with:
            image-ref: node:23.2.0-alpine3.20
            severity: CRITICAL,HIGH
            exit-code: 1
            format: table

Then then the second scan will not use format table, as it uses the previously set env var: TRIVY_FORMAT: sarif.

Tests

Here is a workflow run that shows the issue:
input format: table
https://github.com/david-marconis/trivy-ignore-bug/actions/runs/12065562387/job/33644593462#step:3:6
env TRIVY_FORMAT: sarif
https://github.com/david-marconis/trivy-ignore-bug/actions/runs/12065562387/job/33644593462#step:3:20
log indicating sarif mode:
https://github.com/david-marconis/trivy-ignore-bug/actions/runs/12065562387/job/33644593462#step:3:159

Fix

The fix is to check if the actual value differs from the wanted value. You could also remove the check if it is the same as the default, IDK if this has any other implications.

Here is a workflow run with the fix implemented:
https://github.com/david-marconis/trivy-ignore-bug/actions/runs/12065669260/job/33644932663#step:3:217

Fixes

Fixes this issue #438
Might also fix this #435 and #422

@CLAassistant
Copy link

CLAassistant commented Nov 28, 2024

CLA assistant check
All committers have signed the CLA.

@mkjpryor
Copy link

mkjpryor commented Dec 2, 2024

I am also seeing this - it would be great if the fix could be merged and released ASAP.

@simar7
Copy link
Member

simar7 commented Dec 2, 2024

@DmitriyLewen could you take a look?

action.yaml Outdated Show resolved Hide resolved
@DmitriyLewen
Copy link
Contributor

Hello @david-marconis
I played around with this a bit more today.
It seems we can't unset envs from GITHUB_ENV.

I suggest saving and loading envs to a file (to use them locally in trivy-action).
Check out this branch - https://github.com/DmitriyLewen/trivy-action/commits/fix/overwrite-envs/
and test runs - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/12155043324/job/33896010552

Let me know if you have time to test this and update my pr.
If not - no problem - I'll do it when I have time.

Best regards, Dmitriy

@david-marconis
Copy link
Author

Hello @david-marconis I played around with this a bit more today. It seems we can't unset envs from GITHUB_ENV.

I suggest saving and loading envs to a file (to use them locally in trivy-action). Check out this branch - https://github.com/DmitriyLewen/trivy-action/commits/fix/overwrite-envs/ and test runs - https://github.com/DmitriyLewen/test-trivy-action/actions/runs/12155043324/job/33896010552

Let me know if you have time to test this and update my pr. If not - no problem - I'll do it when I have time.

Best regards, Dmitriy

Thanks for taking a look at this Dmitriy. Saving and loading to file might be a better solution than this as it avoids lingering env vars set in GITHUB_ENV.

I'll leave my PR like it is now, it is at least better that the current solution and isn't very complicated. It fixes some of the issues, but not all, and I don't believe it causes any regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants