Skip to content

🌱 (ci) - Add test for release mock #4939

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jul 23, 2025
+59 −0
Merged

🌱 (ci) - Add test for release mock #4939

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions .github/workflows/release-version-ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
name: Test GoReleaser and CLI Version

on:
push:
paths:
- 'pkg/cmd/**'
- 'build/.goreleaser.yml'
- '.github/workflows/release-version-ci.yml'
pull_request:
paths:
- 'pkg/cmd/**'
- 'build/.goreleaser.yml'
- '.github/workflows/release-version-ci.yml'

jobs:
mock-build:
runs-on: ubuntu-latest

steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 0

- name: Set up Go
uses: actions/setup-go@v5
with:
go-version-file: go.mod

- name: Clean dist directory
run: rm -rf dist || true

- name: Create temporary git tag
run: |
git tag v4.5.3-rc.1

- name: Install Syft to generate SBOMs
run: |
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b $HOME/bin
echo "$HOME/bin" >> $GITHUB_PATH

- name: Run GoReleaser in mock mode using tag
uses: goreleaser/goreleaser-action@v6
with:
version: v2.7.0
args: release --skip=publish --clean -f ./build/.goreleaser.yml

- 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
Comment on lines +48 to +59
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Suggested change
- 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'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading