🌱 (ci) - Add test for release mock #4939
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
the
size/M
camilamacedo86
force-pushed
the
test-release
branch
6 times, most recently
from
559fefa to
e7c407f
Compare
camilamacedo86
changed the title
camilamacedo86
force-pushed
the
test-release
branch
from
e7c407f to
4633ef3
Compare
camilamacedo86
force-pushed
the
test-release
branch
from
4633ef3 to
2293989
Compare
| - name: Init project using built kubebuilder binary and check cliVersion | ||
| run: | | ||
| mkdir test-operator && cd test-operator | ||
| go mod init test-operator | ||
| chmod +x ../dist/kubebuilder_linux_amd64_v1/kubebuilder | ||
| ../dist/kubebuilder_linux_amd64_v1/kubebuilder init --domain example.com | ||
|
|
||
| echo "PROJECT file content:" | ||
| cat PROJECT | ||
|
|
||
| echo "Verifying cliVersion value..." | ||
| grep '^cliVersion: 4.5.3-rc.1$' PROJECT |
There was a problem hiding this comment.
for the init subcommand we already have e2e-tests. If it's just to test the generated binary via goreleaser, than this might be a simpler approach - WDYT?
| - name: Init project using built kubebuilder binary and check cliVersion | |
| run: | | |
| mkdir test-operator && cd test-operator | |
| go mod init test-operator | |
| chmod +x ../dist/kubebuilder_linux_amd64_v1/kubebuilder | |
| ../dist/kubebuilder_linux_amd64_v1/kubebuilder init --domain example.com | |
| echo "PROJECT file content:" | |
| cat PROJECT | |
| echo "Verifying cliVersion value..." | |
| grep '^cliVersion: 4.5.3-rc.1$' PROJECT | |
| - name: check kubebuilder cliVersion | |
| run: | | |
| echo "Verifying cliVersion value..." | |
| ../dist/kubebuilder_linux_amd64_v1/kubebuilder init | grep '4.5.3-rc.1' |
There was a problem hiding this comment.
I think it is nice we have the content in case it fails, so we do not need to take the steps locally to discover the reason. WDYT? Could we proceed as it is?
There was a problem hiding this comment.
sure, we can proceed as it is.
The following is just a small Feedback from a new contributor PoV:
I totally got your intention and the way you've implemented this, is definitely cool.
But I also love the "defacto standard" in the k8s ecosystem where mostly a make lint && make test works out of the box on my machine and I get early feedback - even before i push and raise a PR.
And sometimes users have to spend more time in understanding and fixing code/tests which are not covered by a local test setup (which sometimes isn't that easy for sure).
Having this scenario as ginkgo based e2e-test would make it more accessible, as at least the .github folder is something I mostly do not care about.
But this also introduces new complexity - and we have to deal with that as well.
There was a problem hiding this comment.
We use Goreleaser and GitHub Actions for our release process.
This test is specifically validating Goreleaser / Release process
Why do we check the CliVersion?
Because it's only output from the Binary released.
(tag version);Not from the one build with make install.
See: https://github.com/kubernetes-sigs/kubebuilder/blob/master/build/.goreleaser.yml#L35
That’s why this doesn’t quite fit in the standard GoLang e2e test suite—what we really want is to test the release process itself, not just the CLI in isolation.
|
/lgtm |
|
@bavarianbidi: changing LGTM is restricted to collaborators In response to this:
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-sigs/prow repository. |
camilamacedo86
added
the
lgtm
No description provided.