Skip to content

Test GitHub Actions scaffolded and fix them if requiredΒ #4977

@camilamacedo86

Description

@camilamacedo86

What to do

  • Scaffold a new project using Kubebuilder
  • Push the project to a new GitHub repository
  • Verify that all GitHub Actions run and pass

Test the following scenarios (including combinations of options):

We need to cover a range of project configurations to ensure that all scaffolded variants are CI-compliant. Refer to:
https://github.com/kubernetes-sigs/kubebuilder/blob/master/test/testdata/generate.sh

Test Scenarios & Commands

These are the scenarios to test for GitHub Actions using Kubebuilder scaffolds. Each block includes the commands needed to generate the project variant.

  • Scenario 1: init only (basic init)
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"
  • Scenario 2: create api (single API)
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"
kubebuilder create api --group crew --version v1 --kind Captain --controller=true --resource=true
  • Scenario 3: create webhook (with multigroup API)
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"
kubebuilder edit --multigroup=true
kubebuilder create api --group crew --version v1 --kind Captain --controller=true --resource=true
kubebuilder create webhook --group crew --version v1 --kind Captain --defaulting --programmatic-validation
  • Scenario 4: Project with 2 APIs and webhooks in different groups using edit --multigroup=true
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"
kubebuilder edit --multigroup=true

# API 1 + webhook
kubebuilder create api --group crew --version v1 --kind Captain --controller=true --resource=true
kubebuilder create webhook --group crew --version v1 --kind Captain --defaulting

# API 2 + webhook
kubebuilder create api --group ship --version v1 --kind Destroyer --controller=true --resource=true
kubebuilder create webhook --group ship --version v1 --kind Destroyer --programmatic-validation
  • Scenario 5: Project with API + Webhooks and Helm Chart
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"
kubebuilder create api --group example.com --version v1 --kind App --controller=true --resource=true
kubebuilder create webhook --group example.com --version v1 --kind App --defaulting

kubebuilder edit --plugins=helm.kubebuilder.io/v1-alpha
  • Scenario 6: Project with Deploy Image plugin and Helm Chart
kubebuilder init --plugins="go/v4" --domain testproject.org --license apache2 --owner "The Kubernetes authors"

kubebuilder create api --group example.com --version v1alpha1 --kind Memcached \
  --image=memcached:1.6.26-alpine3.19 \
  --image-container-command="memcached,--memory-limit=64,-o,modern,-v" \
  --image-container-port="11211" \
  --run-as-user="1001" \
  --plugins="deploy-image/v1-alpha"

kubebuilder create webhook --group example.com --version v1alpha1 --kind Memcached --programmatic-validation

kubebuilder edit --plugins=helm.kubebuilder.io/v1-alpha

If actions fail

  • Fix the scaffolded code and/or GitHub Actions accordingly
  • The Kubebuilder scaffold must produce projects that pass all GitHub Actions without manual edits

Done when

  • New repo is created and pushed
  • All actions pass
  • All scenarios above are tested
  • Fixes are applied if any workflows fail

IMPORTANT: If you encounter issues that you are unable to fix right away, that's totally fine. The most important thing is that all scenarios are tested, and any problems are tracked by opening separate issues. This way, we can ensure nothing is missed and tackle each case methodically.

πŸ‘₯ Collaboration:
More than one person can work on this. The goal is to validate all the scenarios listed above.
Just sync via Slack to ensure that you are not testing the same scenario of another person

πŸ“¦ PR Guidelines:
Please make sure to submit one PR per fix so that each issue is easier to review, track, and roll back if needed.

Metadata

Metadata

Labels

api-reviewCategorizes an issue or PR as actively needing an API review.good first issueDenotes an issue ready for a new contributor, according to the "help wanted" guidelines.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.size/MDenotes a PR that changes 30-99 lines, ignoring generated files.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions