✨ Update component-config tutorial automatically

[Eileen-Yu]

Description:

1. Automatically update the scaffolded project of the component-config tutorial.
2. Introduce a new CI pipeline for docs

Motivation:

Attempt to discuss the implementation and try to solve the first part of #2510

[k8s-ci-robot]

Hi @Eileen-Yu. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Kavinjsir]

Nice job @Eileen-Yu 👍🏼 !
I did a first-round review and left some comments.
Will take another look later.
Thx for participating in contribution!

[camilamacedo86]

we do not need to do those calls.
Whe we can add those via the Makefile right?

[Eileen-Yu]

Hi @camilamacedo86 I have a question here:

I can understand that if we run make generate, the build_kb will be loaded and kubebuilder would be built.

What I'm thinking is, if it's necessary to have a separate cmd, that can individually generate docs based on the code?

What we have now is make generate-docs, that does not include build_kb.

[Kavinjsir]

nits: what about merging the two lines:

(cd docs/book/src/component-config-tutorial/testdata/project; make build)

(Assuming in the future we may go to multiple tutorial directories and run the command..)

[camilamacedo86]

We do not need the make build to do this one.
The build will be made in the ci already before we call make generate
Locally the contributor should work with make generate so, IMO we should keep the same behaviour.

[Eileen-Yu]

Do we have the step to execute codegen for those tutorials in the CI?

I failed to find the place. Do you have the reference?

[camilamacedo86]

We call in the CI make check-testdata, see: https://github.com/kubernetes-sigs/kubebuilder/blob/master/.github/workflows/testdata.yml#L27

Then, see that this target calls ./test/testdata/check.sh: https://github.com/kubernetes-sigs/kubebuilder/blob/master/Makefile#L120-L122

See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/testdata/check.sh#L17-L39

So, my thought, in the long run, is we have a makefile target that calls that run the go implementation to generate docs/ Also, add this one to make generate. And then, ensure that we are testing/checking for all PR changes if the docs were also generated/is updated accordingly.

Is that make sense? Such as we do in SDK to verify the samples as well.

[camilamacedo86]

/ok-to-test

That is a terrific contribution 🥇
Just a few nits, and then it will be great to get merged.

[camilamacedo86]

@Eileen-Yu , why are we calling the make build in the shell?
We can call that via golang see, i.e. https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/e2e/v4/plugin_cluster_test.go#L118

So, we can make("build") as well.

[Kavinjsir]

See that CI has reported an error for missing kubebuilder. That is possibly due to the execution of make generate-docs without build_kb.

I think we might have two approaches:

1. In the new ci yaml file, add the setup to load and run build_kb, and then execute make generate-docs.
2. Drop this new ci file, and add generate-docs to make generate.

WDYT? @Eileen-Yu @camilamacedo86

Well, I like the idea to have a separate pipeline focusing on docs validation.

[camilamacedo86]

I think we should not use build_kb and we should do == make generate and the make target and ci that check the testdata

[Kavinjsir]

Hi @camilamacedo86
It makes sense to integrate the docs generation into check-the-testdata, that can make the implementation a lot easier and straightforward.
Based on that, I'm concerned about some following points:

1. If CI fails at check the testdata, will it become hard to tell at the first glance which part is wrong: either testdata OR docs?
2. Would it be slow if we run all the generations in one pipeline versus having multiple pipelines for each generation?
3. Is the priority of keeping testdata consistent higher than docs?

[camilamacedo86]

It is OK to be another CI test. I am just saying that the implementation is very similar == to the target to generate the testdata samples and check it out.

[Eileen-Yu]

Hi @camilamacedo86 I just added CI for the docs check.
Could you pls help with review?

@Kavinjsir It sounds good to have multiple pipelines. How would you like to deal with this in some future PR?

[camilamacedo86]

That is terrific work 🥇

@Kavinjsir I think all your comments are addressed. So, I am moving forward, but if you see a hall for improvements/changes, please track those issues, and we can try to address them in a fallow up.

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, Eileen-Yu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [camilamacedo86]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment