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

Use gengo/v2 in kube-openapi #458

Merged
merged 24 commits into from Feb 26, 2024
Merged

Use gengo/v2 in kube-openapi #458

merged 24 commits into from Feb 26, 2024

Conversation

thockin
Copy link
Member

@thockin thockin commented Feb 26, 2024

This is needed to support Go workspaces in k/k.

This is done as several small commits so each step can be seen. It has the unfortunate effect of not compiling at each step.

@liggitt @alexzielenski @jpbetz

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Feb 26, 2024
Copy link
Member

@liggitt liggitt left a comment

Choose a reason for hiding this comment

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

just a couple comments

is the k/k PR updated with a temporary replace of this to make sure it works properly in context there?

"the name of the file to be generated")
fs.StringVar(&args.GoHeaderFile, "go-header-file", "",
"the path to a file containing boilerplate header text; the string \"YEAR\" will be replaced with the current 4-digit year")
fs.StringVarP(&args.ReportFilename, "report-filename", "r", "-",
Copy link
Member

Choose a reason for hiding this comment

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

nit: use the c.ReportFilename current field value (defaulted in New()) rather than stomping a hard-coded string - here?

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed in next push

GeneratorFunc: func(c *generator.Context) (generators []generator.Generator) {
return []generator.Target{
&generator.SimpleTarget{
PkgName: filepath.Base(args.OutputDir),
Copy link
Member

Choose a reason for hiding this comment

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

is filepath.Base(args.OutputDir) actually correct for finding the package name, or is it best-effort / usually-correct? if the latter, comment here to note that limitation and possibly for a follow-up improvement

would path.Base(args.OutputPackage) be more likely to be correct (though still possibly best-effort) - path instead of filepath, customArgs.OutputPackage instead of arguments.OutputBase?

Copy link
Member Author

Choose a reason for hiding this comment

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

Correct on Pkg vs Dir.

filepath touches a few more places.

@liggitt
Copy link
Member

liggitt commented Feb 26, 2024

hmm, integration test CI looks unhappy

@thockin
Copy link
Member Author

thockin commented Feb 26, 2024

Yeah, I am looking at it.

TL;DR: it seems to run openapi-gen and then re-run it witrh --verify. I must be misunderstanding it.

@Jefftree
Copy link
Member

We have a separate go.mod file for the integration test directory. I'm assuming the go.mod there needs to be updated as well

This does not fix all the logic.  That will be done subsequently.

TO REPEAT:

    git grep -l 'k8s.io/gengo/[^v][^2]' \
        | while read F; do \
            sed -i 's|k8s.io/gengo/\([^v]\)|k8s.io/gengo/v2/\1|' $F
        done
Also get rid of targetPackage - it's not a package, it's a directory.
We can't pretend an arbitrary output dir is a Go package or that the
directory path has anything to do with the package name.  Go is
particular in its definition - a package has at least one .go file in
it.  If the output dir doesn't (yet), then it's not a resolvable
package - even if it SEEMS like it should be.

Fortunately, since the directory we emit to is never one of the input
directories, we don't need to try to elide the "local" package name from
type references.  Also, we don't actually make any such type references.

If that were to change, we could easily adapt - scan the inputs'
SourcePaths for the output dir and, IFF found, pass it down.  But the
odds of needing that are ~0 at this point.
If it does fail, it is catastophic.  Don't bother trying to handle it.
@thockin
Copy link
Member Author

thockin commented Feb 26, 2024

Test should pass now.

The integration test at HEAD is B-R-O-K-E-N. Running it man ually leaves uncommitted changes, but the test passes. The test itself runs openapi-gen (which generates a delta) then runs a verify against the fresh delta, which passes. The test could literally never fail (unless it exits non-zero).

I don't know why the delta exists. It seems to be a regression in formatting? See d1213fd

If the delta is expected, it's fixed here. If not, someone show me why?

This PR now changes the test to generate code into the temp dir and diff, just like it does for the reports and other files.

@liggitt
Copy link
Member

liggitt commented Feb 26, 2024

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 26, 2024
@liggitt
Copy link
Member

liggitt commented Feb 26, 2024

/approve
/hold for good kube-openapi output in the k/k PR that pulls this in

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 26, 2024
@thockin
Copy link
Member Author

thockin commented Feb 26, 2024

I can't really fix k/k until this merges, but almost all of these commits came straight out of my k/k tree

/remove-hold

@thockin
Copy link
Member Author

thockin commented Feb 26, 2024

/unhold

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 26, 2024
@alexzielenski
Copy link
Contributor

/hold cancel

@alexzielenski
Copy link
Contributor

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexzielenski, liggitt, thockin

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 26, 2024
@k8s-ci-robot k8s-ci-robot merged commit ee7ae60 into kubernetes:master Feb 26, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants