-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 custom image update and relocation #3711
Scorecard custom image update and relocation #3711
Conversation
…erator-sdk into scorecard-custom-image
to produce the custom-scorecard-tests image. This makes it | ||
easier to build the image using the normal build process and | ||
will make testing the custom image easier, which will be | ||
addressed in another PR. |
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.
Would this affect the users? if not, I do not think that we need the fragment.
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.
this PR doesn't impact users yet, another forthcoming PR however will make a change to the website docs to update some links to the new relocated file locations, so I'll add the changelog into that PR.
…log fragment, will add a changelog in upcoming PR
[scorecard_binary]: https://github.com/operator-framework/operator-sdk/blob/master/internal/scorecard | ||
[sample_makefile]: https://github.com/operator-framework/operator-sdk/blob/master/internal/scorecard |
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.
Both of these links point to the same code, and neither are really pointing to what they describe. Can you update/remove the sections these links are used in?
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 was going to update these in a docs PR after this one that fixes those links to the newly relocated locations, this is essentially just making the link-checker happy till I can get the docs PR merged next.
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.
it is because you are using the link. I think it should work with relative paths point for the code directly. e.g operator-sdk/internal/scorecard/examples/custom-scorecard-tests/Makefile
case CustomTest1Name: | ||
result = CustomTest1(cfg) | ||
case CustomTest2Name: | ||
result = CustomTest2(cfg) |
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.
Can we have just 2 custom tests? I did not get this part.
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.
this is just an example of a custom image, it has 2 tests that essentially are no-op's to just show the structure of what a custom image looks like, real custom images that an ISV would build would have any number of tests in reality.
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.
it has 2 only as an example....a custom image can support any number of tests.
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.
Overall looks good, just a question regarding s390x.
Makefile
Outdated
ANSIBLE_ARCHES:="amd64" "ppc64le" "s390x" "arm64" | ||
HELM_ARCHES:="amd64" "ppc64le" "s390x" "arm64" | ||
CUSTOM_SCORECARD_TESTS_ARCHES:="amd64" "ppc64le" "s390x" "arm64" | ||
SCORECARD_TEST_ARCHES:="amd64" "ppc64le" "s390x" "arm64" | ||
SCORECARD_TEST_KUTTL_ARCHES:="amd64" "ppc64le" "s390x" "arm64" |
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.
Are we adding s390x back in? @joelanford thoughts? Travis support did say things should be working again.
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.
IHMO we need at least add a comment to clarifies that these images are just examples for the doc and are not required for the tool or its features work at all.
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.
removed the 390x from the ARCHES to match what is on master right now, also added a comment in the makefile about the scorecard custom image being an example.
migration: | ||
header: Update scorecard-test-kuttl image to use latest kuttl | ||
body: | | ||
The scorecard-test-kuttl image is updated to use kuttl:v0.5.2 | ||
as the base image. |
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.
Is a migration really required?
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.
hmmn, actually that fragment is already merged into master, the way I understood migration was that it would require a change on the user's part to do something, e.g. like migrate their kuttl tests to the new image version. But I could have misunderstood the intent of the migration section.
# Scorecard test kuttl image scaffold/build/push. | ||
.PHONY: image-build-scorecard-test-kuttl image-push-scorecard-test-kuttl image-push-scorecard-test-kuttl-multiarch | ||
|
||
image-build-custom-scorecard-tests: | ||
./hack/image/build-custom-scorecard-tests-image.sh $(CUSTOM_SCORECARD_TESTS_BASE_IMAGE):dev | ||
|
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.
IHMO we should not add more images since we have a lot already just for the tests. We could provide the code and doc how the users can build and push for their registry instead.
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.
@joelanford Joe should probably decide if this example image lives inside this repo or outside in a separate repo (e.g. operator-sdk-samples). I'm fine either way. If its outside the repo then it will likely require on-going maintenance or some other external test to insure it does not get stale.
@@ -4,14 +4,14 @@ metadata: | |||
name: config |
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.
The testdata/ dir has a special meaning for GO and IHMO all examples should be in the testdata dir.
@@ -78,10 +77,52 @@ func printValidTests() scapiv1alpha3.TestStatus { | |||
result.Suggestions = make([]string, 0) |
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.
IHMO all code in the internal/ dir should be related to an internal implementation of the CLI features. We should not add examples inside that since they are not really internal.
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.
IHMO we need to think better about how these examples have been introduced and perform cleanup on it. In POV all that is an example should be in a dir called testdata/
since it has an especial meaning for Go and not be part of the internal dirs since are not related to the internal implementation as well.
However, I can be ok with we move forward with this PR and working on on the concerns raised in a follow up only if remove/or change what has been introduced here would NOT be considered a breaking(which I understand that it is the case 👍 )
But shows still a blocker to get it merged, anyway:
- Not introduce the code to build image s390x (@jmrodri comment)
- Ensure that we have comments in the makefile and code to clarifies that it is about examples. I mean, when we look on the Makefile ought to be very clear what images we need to build because they are part of the CLI features and what images are just examples for the users check how the things work.
…mment about the scorecard custom image
Description of the change:
this PR moves the sample scorecard custom test image into a similar location as the other scorecard test images.
Motivation for the change:
Having the sample custom test image built like the other scorecard test images makes it more consistent
from the user's standpoint and also more consistent to have the sample built along with the other scorecard
test images which is useful for ensuring the sample doesn't get stale. This PR also makes testing the custom
test image easier with the typical e2e testing which will be provided in another PR.
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments
(seechangelog/fragments/00-template.yaml
)website/content/en/docs