🐛 crd: add integration test for indirect type alias resolution (#1063) by meliezer · Pull Request #1344 · kubernetes-sigs/controller-tools

meliezer · 2026-02-16T17:40:37Z

Adds regression coverage for the scenario reported in #1063.

In controller-tools v0.16.x, CRD generation could panic when a root API type
contained a field defined via a type alias whose target type lived in a package
not directly imported by the root package.

This PR adds integration-level coverage using the existing Ginkgo/Gomega test
pattern in parser_integration_test.go:

runs from the pkg/crd/testdata module
uses loader.LoadRoots and parser APIs
avoids subprocess execution

The test uses a descriptive fixture layout to model the alias chain:
rootpkg → aliaspkg → targetpkg

Also removes the previous subprocess-based test approach and replaces it with
the standard integration test structure used in this package.

The issue no longer reproduces on main (and v0.20.1), likely fixed as a side
effect of #1122. This test ensures the behavior remains covered and prevents
future regressions.

Signed-off-by: Menashe Eliezer <menashe.eliezer@gmail.com>

k8s-ci-robot · 2026-02-16T17:40:44Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: meliezer
Once this PR has been reviewed and has the lgtm label, please assign sbueringer for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

OWNERS

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

linux-foundation-easycla · 2026-02-16T17:40:44Z

The committers listed above are authorized under a signed CLA.

✅ login: meliezer / name: Menashe Eliezer (3ede5b1, 87cdff2)

k8s-ci-robot · 2026-02-16T17:40:46Z

Welcome @meliezer!

It looks like this is your first PR to kubernetes-sigs/controller-tools 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/controller-tools has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

k8s-ci-robot · 2026-02-16T17:40:47Z

Hi @meliezer. 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.

Details

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.

sbueringer · 2026-02-17T08:25:05Z

@@ -0,0 +1,91 @@
+package crd_test


Sorry not sure I follow why this test cannot be added like all our other tests

Thanks for taking a look! The only reason this test runs controller-gen from pkg/crd/testdata is that pkg/crd/testdata is its own Go module (module testdata.kubebuilder.io/cronjob in pkg/crd/testdata/go.mod).

The repro packages live under that module (testdata.kubebuilder.io/cronjob/issue1063/...). If the test runs controller-gen with cmd.Dir set to the repo root (main module), go/packages ends up trying to resolve those imports from the main module and fails with “no required module provides package …/issue1063/repro2”. Running from the testdata module root makes the imports resolve exactly as intended and matches how this repository already structures other fixtures under pkg/crd/testdata.

I can add a short comment in the test explaining this (pkg/crd/testdata is a separate module; run controller-gen from there so package resolution uses that go.mod) if that helps readability.

If you prefer a different pattern that keeps cmd.Dir at repo root (e.g. setting GOMOD/-C), I’m happy to adjust, but I wasn’t able to make that work reliably with go/packages without executing inside the testdata module.

I was just naively wondering what makes this test different from the ones in parser_integration_test.go

Thanks for the question, and for your patience.
The existing tests in parser_integration_test.go are close, but they exercise the parser through the internal API (loader.LoadRoots + parser.NeedPackage/NeedCRDFor) after chdir-ing into pkg/crd/testdata.

This test is intentionally a bit different: it runs controller-gen end-to-end as a subprocess, from the existing pkg/crd/testdata module (testdata.kubebuilder.io/cronjob). That matters for the #1063 scenario because the historical failure was tied to package/module resolution for the alias chain repro1 -> repro2 -> repro3, where the target type lived in a package not directly imported by the root package.

So the overlap is real, but this adds regression coverage for the CLI/module-resolution path rather than only the parser API path.

If you’d prefer, I can also rework it into parser_integration_test.go, but I wanted to keep the test exercising the exact module-resolution setup that originally made this scenario fail.

I think, I understand the concern, but this is already solved by the existing test pattern. Look at parser_integration_test.go lines:

By("switching into testdata to appease go modules") prevCwd, err = os.Getwd() Expect(err).NotTo(HaveOccurred()) Expect(prevCwd).To(BeADirectory()) Expect(os.Chdir("./testdata")).To(Succeed()) // ← Here we have the magic

All existing tests:

Change directory to testdata (separate module)

Call loader.LoadRoots()

The loader uses the testdata/go.mod for resolution

This is exactly the same as running controller-gen from the testdata directory, but using internal APIs instead of subprocess.

camilamacedo86 · 2026-04-19T12:13:37Z

@@ -0,0 +1,4 @@
+// Package repro1 contains API Schema definitions.


Instead of issue number and repro1 and etc
Could we add meaningful names?

Something like

pkg/crd/testdata/ └── typealiasindirect/ ├── rootpkg/ │ ├── doc.go // Package doc with kubebuilder markers │ └── types.go // CRD with field using alias from aliaspkg ├── aliaspkg/ │ └── alias.go // type MyAlias = targetpkg.TargetStruct └── targetpkg/ └── types.go // The actual struct definition

Also, it seems that would fit better to pkg/crd/parser_integration_test.go or create pkg/crd/type_alias_integration_test.go

camilamacedo86 · 2026-04-19T12:15:40Z

+)
+
+// repoRoot walks up from this test file until it finds the repository go.mod.
+func repoRoot(t *testing.T) string {


The tests should follow the project standards that means BBD style and use;

. "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Could you please check the other integration and tests in the project?

camilamacedo86

Thanks for adding regression coverage for this. The scenario is valid and worth testing. 🎉

I do think the test should be refactored before merge so it matches the existing patterns in this package.

The main changes I’d ask for are:

Please rewrite it in the existing Ginkgo/Gomega style instead of testing.T
Please avoid the subprocess approach here and use the internal parser APIs instead
Please rename the testdata packages to something descriptive, so the scenario is easier to understand when reading the fixture layout

I think the internal API path should work for this case too. The existing integration tests already change into testdata to use that module’s go.mod, then call loader.LoadRoots(...). That seems like the right fit here as well, and it keeps this test consistent with the rest of the suite.

I’d also suggest renaming the fixture packages from repro1/repro2/repro3 to names that describe their role in the alias chain. That will make the test much easier to follow later.

So overall: good regression test, but It think it need to be rewritten to follow the established integration-test structure before merging.

camilamacedo86 · 2026-04-19T12:19:36Z

@@ -0,0 +1,91 @@
+package crd_test


I think, I understand the concern, but this is already solved by the existing test pattern. Look at parser_integration_test.go lines:

By("switching into testdata to appease go modules") prevCwd, err = os.Getwd() Expect(err).NotTo(HaveOccurred()) Expect(prevCwd).To(BeADirectory()) Expect(os.Chdir("./testdata")).To(Succeed()) // ← Here we have the magic

All existing tests:

Change directory to testdata (separate module)

Call loader.LoadRoots()

The loader uses the testdata/go.mod for resolution

This is exactly the same as running controller-gen from the testdata directory, but using internal APIs instead of subprocess.

camilamacedo86 · 2026-04-19T12:26:07Z

@@ -0,0 +1,4 @@
+// Package repro1 contains API Schema definitions.


Something like

pkg/crd/testdata/ └── typealiasindirect/ ├── rootpkg/ │ ├── doc.go // Package doc with kubebuilder markers │ └── types.go // CRD with field using alias from aliaspkg ├── aliaspkg/ │ └── alias.go // type MyAlias = targetpkg.TargetStruct └── targetpkg/ └── types.go // The actual struct definition

Also, it seems that would fit better to pkg/crd/parser_integration_test.go or create pkg/crd/type_alias_integration_test.go

meliezer · 2026-04-19T13:48:16Z

Thanks for the detailed feedback — that makes sense.

You’re right that the existing integration-test pattern already handles the separate testdata module correctly by switching into pkg/crd/testdata before calling loader.LoadRoots(...), so there’s no real need for the subprocess approach here.

I’ll rework this to follow the existing Ginkgo/Gomega integration style, use the internal parser APIs, and rename the fixture packages to something more descriptive for the alias chain scenario. I also agree it fits better alongside the existing parser integration coverage.

Thanks again — I’ll update the PR accordingly.

Add regression coverage for the scenario reported in kubernetes-sigs#1063, where CRD generation could panic when a root type used a type alias whose target type lived in a package not directly imported by the root package. The test follows the existing Ginkgo/Gomega integration pattern in parser_integration_test.go and uses the existing testdata module for package resolution. Also remove the earlier subprocess-based test and rename fixtures to reflect the alias chain scenario more clearly. Likely addressed by kubernetes-sigs#1122; this test prevents regressions.

meliezer · 2026-04-19T20:06:54Z

Thanks for the guidance — I’ve updated the PR to follow the existing integration-test pattern.

The test now:

uses the internal parser APIs (loader.LoadRoots + parser)
runs from the existing pkg/crd/testdata module
avoids subprocess execution
uses more descriptive fixture names for the alias chain

I’ve also updated the PR description to reflect the current approach.

crd: add regression test for type alias deps not directly imported

87cdff2

Signed-off-by: Menashe Eliezer <menashe.eliezer@gmail.com>

k8s-ci-robot requested a review from JoelSpeed February 16, 2026 17:40

k8s-ci-robot requested a review from sbueringer February 16, 2026 17:40

k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Feb 16, 2026

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Feb 16, 2026

sbueringer reviewed Feb 17, 2026

View reviewed changes

camilamacedo86 reviewed Apr 19, 2026

View reviewed changes

camilamacedo86 suggested changes Apr 19, 2026

View reviewed changes

k8s-ci-robot assigned camilamacedo86 Apr 19, 2026

k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Apr 19, 2026

meliezer changed the title ~~🐛 crd: add regression test for type alias deps not directly imported~~ 🐛 crd: add integration test for indirect type alias resolution (#1063) Apr 19, 2026

		@@ -0,0 +1,4 @@
		// Package repro1 contains API Schema definitions.

Conversation

meliezer commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Feb 16, 2026

Uh oh!

linux-foundation-easycla Bot commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Feb 16, 2026

Uh oh!

k8s-ci-robot commented Feb 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camilamacedo86 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

meliezer commented Apr 19, 2026

Uh oh!

meliezer commented Apr 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

meliezer commented Feb 16, 2026 •

edited

Loading

linux-foundation-easycla Bot commented Feb 16, 2026 •

edited

Loading

camilamacedo86 left a comment •

edited

Loading