-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
scorecard: make config a componentconfig, scaffold config kustomization on init
#3490
scorecard: make config a componentconfig, scaffold config kustomization on init
#3490
Conversation
9d6e509
to
10fd41d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
happy path testing shows it working.
10fd41d
to
16dee30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass (don't have time for a long review at the moment).
I saw some references to generate kustomize scorecard
still. That's no longer in the PR, right?
generate kustomize scorecard
subcommandinit
init
init
versioned with other scorecard APIs in `pkg/apis/scorecard/v1alpha3`. It also adds the `generate kustomize scorecard` subcommand, which scaffolds componentconfig bases and patches in `config/scorecard`. `generate kustomize manifests` will add the scorecard kustomize path to the manifests kustomization.yaml, and `generate bundle` will write the scorecard config to `bundle/tests/scorecard/config.yaml` cmd/operator-sdk/generate: add `kustomize scorecard` subcommand and modify `kustomize manifests` subcommand pkg/apis/scorecard/v1alpha3: add ScorecardConfiguration types that map to the original Config's types internal/scorecard: replace Config type with v1alpha3.ScorecardConfiguration and related types
27c2806
to
3d7fdb5
Compare
website/content/en/docs/advanced-topics/scorecard/custom-tests.md
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,259 @@ | |||
// Copyright 2020 The Operator-SDK Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it should be with the other SDK customizations in operator-sdk/internal/util/plugins/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hesitant to start throwing things into internal/util/plugins
like we did with the bundle stuff. Eventually we'll have a bunch of unrelated phase 2-like plugin code in there, and have the mess we currently have in a bunch of internal/util
subpackages. The scorecard config scaffold will eventually be its own phase 2 plugin I expect, so should live here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @estroz's sentiment. Maybe as a follow-up we should move the "OLM"-like plugin stuff from operator-sdk/internal/util/plugins/
back into internal/plugins/olm
And then also try to refactor them to look as much like what we think phase 2 plugins will look like. Given that we're duplicating the kubebuilder
machinery code, I think we could refactor these to use the scaffold and template interfaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with you will do olm, scorecard and etc .. then I am ok with. I just do not like the idea of each requirement be solved in a diff way.
patchesJson6902: | ||
{{- range $i, $patch := .JSONPatches }} | ||
- path: {{ $patch.Path }} | ||
target: | ||
group: {{ $patch.Target.Group }} | ||
version: {{ $patch.Target.Version }} | ||
kind: {{ $patch.Target.Kind }} | ||
name: {{ $patch.Target.Name }} | ||
{{- end }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why we do not it as the watches and the other features in kb and helm as well?
IMO we should use the default kubebuilder markers instead of that. E.g # +kubebuilder:scaffold:scorecard
. I do not think that is following the current design. Note that kb has a lot of helpers for the markers which indeed let us mock the tests which will not be possible to be used here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we would be defining our own struct for a kustomize type. This type may exist in the kustomize codebase, but I'd rather not import kustomize libraries if we don't have to.
69916b7
to
aaf7764
Compare
aaf7764
to
5ece020
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
after addressing above comment about the marker
5ece020
to
75b2dfc
Compare
New changes are detected. LGTM label has been removed. |
Description of the change:
config/scorecard
kustomize scaffoldsMotivation for the change: This PR modifies the scorecard config to be a componentconfig versioned with other scorecard APIs in
pkg/apis/scorecard/v1alpha3
. It also addsconfig/scorecard
kustomize scaffolds toinit
, which writes componentconfig bases and patches toconfig/scorecard
.generate kustomize manifests
will add the scorecard kustomize path to the manifests kustomization.yaml, andgenerate bundle
will write the scorecard config tobundle/tests/scorecard/config.yaml
/cc @jmccormick2001
/kind feature
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments
(seechangelog/fragments/00-template.yaml
)website/content/en/docs