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 publish workflow failure with the new trivy action changes #7385

Closed
TharmiganK opened this issue Nov 20, 2024 · 3 comments · Fixed by #7386
Closed

Fix publish workflow failure with the new trivy action changes #7385

TharmiganK opened this issue Nov 20, 2024 · 3 comments · Fixed by #7386

Comments

@TharmiganK
Copy link
Contributor

TharmiganK commented Nov 20, 2024

Description

With the latest trivy action version, the caching is enabled by default. The cache will be stored in $GITHUB_WORKSPACE/.cache/trivy. More information can be found here.

Since the libraries does not ignore this specific directory - .cache, the gradle release sub task - checkCommitNeeded will fail since this directory is not committed. Sample failure can be found here.

There are two possible options to resolve this issue:

  • Option 1: Disable caching in the trivy action step for publish workflow
  • Option 2: Add .cache/ to the .gitignore file of each repository

I prefer the Option 1 since it requires the least changes

Version

Ballerina SwanLake Update 11

@NipunaRanasinghe
Copy link
Contributor

NipunaRanasinghe commented Nov 20, 2024

@TharmiganK is there a significant time difference when Trivy caching is disabled?
If we can come up with those numbers it'll be easier to decide between option 1 and option 2 based on the impact. wdyt?

@daneshk
Copy link
Member

daneshk commented Nov 20, 2024

I also encountered this a few times when releasing the library modules and went with option 2. As per the document referred to, if we disable it, we may experience rate-limiting issues. Has this caching been enabled recently, as we have seen recently?
Option 02 is safe, as we don't know whether we encounter a rate-limiting issue. But it needs more effort.

@TharmiganK
Copy link
Contributor Author

TharmiganK commented Nov 20, 2024

is there a significant time difference when Trivy caching is disabled? If we can come up with those numbers it'll be easier to decide between option 1 and option 2 based on the impact. wdyt?

The difference is only in seconds. But as @daneshk mentioned caching partially solve the rate-limiting issues and we have added this another fix for rate limiting as well.

Btw I am thinking of a third option which uses this cache-dir option in the trivy action. If we overwrite that to some temporary directory then it won't affect the gradle publish task right?

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        env:
          TRIVY_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-db,public.ecr.aws/aquasecurity/trivy-db
          TRIVY_JAVA_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-java-db,public.ecr.aws/aquasecurity/trivy-java-db
        with:
          scan-type: "rootfs"
          scan-ref: "${{ github.workspace }}/ballerina/lib"
          format: "table"
          timeout: "10m0s"
          exit-code: "1"
          scanners: "vuln"
          cache-dir: "/tmp/trivy-cache"

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

Successfully merging a pull request may close this issue.

3 participants