Skip to content
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.

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

update-codegen.sh doesn't work outside GOPATH #1287

Open
ian-mi opened this issue May 4, 2020 · 8 comments
Open

update-codegen.sh doesn't work outside GOPATH #1287

ian-mi opened this issue May 4, 2020 · 8 comments
Assignees
Labels
area/API kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@ian-mi
Copy link
Contributor

ian-mi commented May 4, 2020

Expected Behavior

hack/update-codegen.sh should work outside of GOPATH

Actual Behavior

update-codegen either does nothing or uses an incorrect pkg version.

Steps to Reproduce the Problem

  1. Move repo outside of GOPATH.
  2. Make a change to the injection generators.
  3. Run ./hack/update-codegen.sh
  4. Observe no change to generated code.
@knative-prow-robot knative-prow-robot added area/API kind/bug Categorizes issue or PR as related to a bug. labels May 4, 2020
@antoineco
Copy link
Contributor

antoineco commented May 5, 2020

I'd love to see this happen too. Unfortunately this has to be tackled in the Kubernetes generators directly. The issue is that those generators always output to {{output-base}}/{{output-package}}/.

Technically, it does work outside of the GOPATH, but your repo needs to be cloned inside a directory matching -output-package exactly. For example, if your code is inside ~/my-knative-eventing and you set -output-base to ../../, all generated files will be written to

~/knative.dev/eventing/pkg/client/...

instead of

~/my-knative-eventing/pkg/client/...

because -output-package is set to knative.dev/eventing.

@Cynocracy
Copy link
Contributor

/assign Cynocracy

I didn't see this before hitting the corner case myself :) I have a hacky attempt at a fix in knative.dev/networking, if it works I can upstream it into library.

@mattmoor
Copy link
Member

cc @n3wscott @imjasonh

@n3wscott
Copy link
Contributor

This is a bug in gengo upstream in Kubernetes.

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 18, 2020
@mattmoor
Copy link
Member

/lifecycle frozen

I believe there's a hack @scothis had that created a temporary GOPATH in ./hack/update-codegen.sh that we could incorporate.

cc @Cynocracy

@knative-prow-robot knative-prow-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Sep 18, 2020
@scothis
Copy link
Contributor

scothis commented Sep 18, 2020

I first saw this pattern in kpack. It basically involves setting up a fake GOPATH for gengo
https://github.com/pivotal/kpack/blob/master/hack/update-codegen.sh#L16-L18

@Cynocracy
Copy link
Contributor

Cynocracy commented Sep 18, 2020

Does this still repro with the new k8s library versions? I was really hoping it did not :(

Fake GOPATH sounds good, we've done similar things internally when we anger the great and powerful Go Mod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API kind/bug Categorizes issue or PR as related to a bug. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
7 participants