controller-get to ignore directories commonly ignored by the go tool

[alcortesm]

The go tool ignores directories that begin with "." or "_", as directories named "testdata", (see here, first occurrence of "ignored by the go tool").

It looks like controller-gen isn't ignoring those directories, nor there is a way to exclude them via command flags.

Would it be possible for controller-gen to obey the same rules as the standard go tool?

Rationale: it is common in CI pipelines to share the go mod cache between runs by storing it in a .go-mod-cache directory at the root of your project, since some CI pipelines (like Gitlab's) impose some limitations on which directories can be cached. As a consequence of this, the controller-gen tries to parse all go files in the mod cache, not just the ones in your project, which takes a long time and often fail since those files don't necesarily have all their dependencies in the mod cache, or they might even be old dependencies prior to go modules.

[JoelSpeed]

Ignoring . directories in particular seems appropriate, since those are often hidden directories in unix systems.

This does have the potential to break users though, so I'd be inclined, if we go for this, to make sure there's a "get out of jail free" card that allows them to opt-in to the old behaviour still

[alcortesm]

Ignoring certain directories will be a breaking change, as you say.

Maybe it would be better to add a way to specify what packages the tool must parse, right now, apparently, it is parsing any go file in the working directory, recursively. It would be good to add a flag to specify the directories or the Go packages to parse. If the flag is not present, then just do what the tool is doing right now.

[sbueringer]

I would be okay with defaulting to ignoring certain directories and providing a way to opt-out.

Not entirely sure if include what to parse or exclude what not to parse would work better.

But I think if the new default behavior would be that folks have to define all folders that should be parsed that would be to big of a breaking change to make that the default behavior. Also it's probably relatively inconvenient to use compared to the current behavior.

Ignoring some directories per default should work for 99% of our users, so I would be fine with making that the default

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.