feat: add type to policy CRD

[binbin-li]

Description

What this PR does / why we need it:

1. Create a new v1beta1 version and add spec.type to the v1beta1 schema.
2. Restrict the metadata.name to be ratify-policy only.
3. Restrict the spec.type to be rego-policy or config-policy only.
4. Update documentation.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):

Fixes #1067

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Helm Chart Change (any edit/addition/update that is necessary for changes merged to the main branch)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

• Test A
• Test B

Checklist:

• Does the affected code have corresponding tests?
• Are the changes documented, not just with inline documentation, but also with conceptual documentation such as an overview of a new feature, or task-based documentation like a tutorial? Consider if this change should be announced on your project blog.
• Does this introduce breaking changes that would require an announcement or bumping the major version?
• Do all new files have appropriate license header?

Post Merge Requirements

• MAINTAINERS: manually trigger the "Publish Package" workflow after merging any PR that indicates Helm Chart Change

[codecov]

Codecov Report

Patch coverage: 43.87% and project coverage change: -5.99% ⚠️

Comparison is base (2274826) 58.31% compared to head (046d519) 52.32%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1079      +/-   ##
==========================================
- Coverage   58.31%   52.32%   -5.99%     
==========================================
  Files          93      101       +8     
  Lines        5546     6291     +745     
==========================================
+ Hits         3234     3292      +58     
- Misses       1996     2682     +686     
- Partials      316      317       +1     

Files Changed	Coverage Δ
api/v1alpha1/policy_types.go	100.00% <ø> (ø)
api/v1alpha1/zz_generated.conversion.go	2.47% <0.00%> (ø)
pkg/controllers/policy_controller.go	65.55% <71.42%> (+15.55%)	⬆️
api/v1alpha1/policy_conversion.go	72.72% <72.72%> (ø)
pkg/policyprovider/factory/factory.go	51.85% <100.00%> (ø)

... and 6 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[susanshi]

i would usually think with PRs introducing new properties, there should be a version update. However customer probably doesn't have any custom policy. Any Policy CR from RC8, would be automatically updated with a CR with the type property. Is that correct? Also interested to hear feedback from @akashsinghal

[binbin-li]

i would usually think with PRs introducing new properties, there should be a version update. However customer probably doesn't have any custom policy. Any Policy CR from RC8, would be automatically updated with a CR with the type property. Is that correct? Also interested to hear feedback from @akashsinghal

good call. I'm open to any advice on version update, I'll wait for more feedback on it as it's not an urgent PR.

[akashsinghal]

i would usually think with PRs introducing new properties, there should be a version update. However customer probably doesn't have any custom policy. Any Policy CR from RC8, would be automatically updated with a CR with the type property. Is that correct? Also interested to hear feedback from @akashsinghal

good call. I'm open to any advice on version update, I'll wait for more feedback on it as it's not an urgent PR.

I think the change not purely additive and is a breaking change if I'm understanding correctly? Ther user will need to update the CR to provide the type of policy in the type field of the spec and also add ratify-policy in the metadata.name field. In that case this would be a breaking change to the v1alpha1 version introduced in rc7.

I think the most thorough way would be to bump the CR version and add the conversion logic between the versions. Now, if we think that disruption will be minimal due to the fact that the original CR was originally introduced in an RC version, then might be ok to not bump.

[akashsinghal]

LGTM. One question: what is the upgrade process like again for the new CRD version? If a user has v1alpha1 already installed, will the next pre-install hook in the new helm chart automatically upgrade. Or does user need to manually delete the old CRD def for policy before the new install?

[binbin-li]

LGTM. One question: what is the upgrade process like again for the new CRD version? If a user has v1alpha1 already installed, will the next pre-install hook in the new helm chart automatically upgrade. Or does user need to manually delete the old CRD def for policy before the new install?

CRD would be auto-installed, but users need to apply new CRs in v1beta1 to make it work.

[susanshi]

LGTM, thanks Binbin