trivyOutputJson.forEach is not a function

[craftyc0der]

I am having 100% failure rate with new and formerly functioning builds with this plugin. It exits with:

Error: trivyOutputJson.forEach is not a function

I've gone to other public repos that use this plugin and see the same errors in their pipelines that worked as late as yesterday afternoon.

Example:
https://github.com/StatCan/aaw-kubeflow-containers/runs/3815148249?check_suite_focus=true

[dagrover-dev]

I am also facing this issue. Since around 3:00am this morning all runs having been failing with the error given above.

It seems a couple days ago trivy updated their json schema: aquasecurity/trivy@b37f682

The error for me coincides with this commit: aquasecurity/trivy@f12446d

[JeffreyArt1]

I am also facing this issue.

[knqyf263]

I'm sorry for the inconvenience. See here for the detail. It should be easy to fix.
aquasecurity/trivy#1050

Also, I recommend pinning the version.

container-scan/src/trivyHelper.ts

Line 18 in 47ffdc2

const trivyLatestReleaseUrl = "https://api.github.com/repos/aquasecurity/trivy/releases/latest";

[spol-vt]

Same here, everything worked OK for weeks, then suddenly as of yesterday getting this error on every run.
This is now blocker for using the action.

[asmirnoff]

Same here, started happening yesterday

[Jose-Matsuda]

Yeah this is a blocker for us as well please merge knqyf263's fix asap!

[abelsromero]

Also, I recommend pinning the version.

A fixed version should be available. Don't mean to be harsh, but I think we all agree breaking builds is not a good thing.

[ajinkya599]

I have updated the action. Can someone please try and share if it works now?

[abelsromero]

It seems to be back, but it'll be nice to know the status of the action. I see a v1 suggestion commit, so if the action is "alpha" it should be stated in the README.

[knqyf263]

@abelsromero No OSS maintainer want to break compatibility, but most OSS, especially maintained for a long time, cannot avoid breaking change for improvements. Updating major version means breaking change in semver. Also, unstable versions might have it.

You will learn something from these docs.
https://cloud.google.com/blog/topics/developers-practitioners/best-practices-dependency-management
https://vsupalov.com/docker-latest-tag/

[djejaquino]

I have updated the action. Can someone please try and share if it works now?

Working for me

[abelsromero]

@abelsromero No OSS maintainer want to break compatibility, but most OSS, especially maintained for a long time, cannot avoid breaking change for improvements. Updating major version means breaking change in semver. Also, unstable versions might have it.

@knqyf263 OSS mantainer myself for years I am lost here. I am well aware of these practices and that why agree with you about pinning versions instead of using "latest" as you pointed out. Either that, or clearly state this is still in developemnt and subject to breakage to keep expectations, I am happy with any of those.

For context, I was suggested to use this action by an official Azure team to meet compliance requirements to deploy a product in Azure. Furthermore this action is under Azure org, and while it uses an OSS licences, it is a MS sponsored (or at least promoted) product, that why I'd expect a more stable product; not perfect, not fast response, not "fix my issue now", just that code does not change if I don't change the version I am pointing at.
If all of these is false, and this is a trully OSS product mantained by a volunteer team in their spare time, under a best-effort manteinance mode, that should also be stated in the README.

[knqyf263]

@abelsromero It makes sense. I agree with you. It is not good that the job fails without any changes. If it is not stable, it should be stated.

[github-actions]

This issue is idle because it has been open for 14 days with no activity.