feat: update verifier reference[WIP]

[junczhu]

Description

What this PR does / why we need it:

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 #1066

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

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (bcade42) 52.31% compared to head (0db8663) 52.62%.
Report is 26 commits behind head on main.

Files	Patch %	Lines
pkg/controllers/verifier_controller.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1150      +/-   ##
==========================================
+ Coverage   52.31%   52.62%   +0.30%     
==========================================
  Files         101      101              
  Lines        6306     6387      +81     
==========================================
+ Hits         3299     3361      +62     
- Misses       2688     2705      +17     
- Partials      319      321       +2     

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

[akashsinghal]

@junczhu Thanks for taking this issue up. It's critical for user flexibility.

I'm a little confused on the implementation. Maybe I'm not understanding #1066. My understanding is that we need to introduce a verifier name and a verifier type to the existing VerifierConfig? This way we can support multiple of the same verifier type. I see that in the verifier controller, the Name field in the VerifierConfig has been set to the objectName which I assume is the spec.metadata.name field (this is the unique verifier identifier and different from the verifier type). The Name field in the VerifierConfig is used to determine whether to run a particular verifier or not on an artifact. Almost closer to a verifier type than the individual verifier spec.metadata.name field. Is there a plan to add some sort of verifiertype field and update the verifier invocation logic to use that?

^^ lot of conflicting terms in that explanation :). I'm happy to clarify offline my confusion too. thanks.

[akashsinghal]

@junczhu I have updated the e2e tests required based on k8s bump and gk bump. Please merge main when you have a chance. Thanks