Add Support for previouse test file structure

[fjogeleit]

Signed-off-by: Frank Jogeleit frank.jogeleit@web.de

Related issue

#2325

What type of PR is this

/kind bug
/kind cleanup

Proposed Changes

Add support for the previous status key in addition to the new result key.

Checklist

• I have read the contributing guidelines.
• I have added tests that prove my fix is effective or that my feature works.
• [] My PR contains new or altered behavior to Kyverno and
  • [] I have added or changed the documentation myself in an existing PR and the link is:
  • [] I have raised an issue in kyverno/website to track the doc update and the link is:
  • [] I have read the PR documentation guide and followed the process including adding proof manifests to this PR.

[realshuting]

Hi @fjogeleit - thanks for the change.

Instead of adding status back to types.go, would it be better to add v1alpha1 schema back under https://github.com/kyverno/kyverno/tree/main/pkg/api/policyreport? This is pretty common in Kubernetes codebase to keep older versions and have all versions of schema generated into the same CRD manifest.

For example, ClusterAPI keeps both v1alpha3 and v1alpha4 in the same manifest, and sets storage=true to indicate which version to store.

Obviously the CLI test command would be impacted, we can add that backward compatibility support (to accpet both status and result)in particular.

[fjogeleit]

Hey @realshuting to handle the old test file structure this change is needed. Support both CRD versions is also possible but could be a separat PR.

[realshuting]

OK, that sounds good. I'll merge this one. Any doc update needed?

[fjogeleit]

Maybe that result should be used and status will be removed in the Future?

I was not sure if you want to add some kind of deprection message

[realshuting]

Maybe that result should be used and status will be removed in the Future?

Sounds good. We can add a comment to this tag indicating status will be dropped in 3 versions ahead. 1.6.0?

Support both CRD versions is also possible but could be a separat PR.

Will you submit a PR for this? Or else we should log an issue to track.

[fjogeleit]

Sounds good. We can add a comment to this tag indicating status will be dropped in 3 versions ahead. 1.6.0?

Okay

Will you submit a PR for this? Or else we should log an issue to track.

An issue would be good, I have to have a look how to work with both CRD versions