Update generated code from latest swagger-codegen #61
Conversation
f7f4517 to
0866c34
Compare
| @@ -0,0 +1 @@ | |||
| 2.3.0-SNAPSHOT No newline at end of file | |||
There was a problem hiding this comment.
I am not sure how acceptable it is to be pointing at -SNAPSHOT here
There was a problem hiding this comment.
Is this an auto-generated file? If it is not, I suggest you add hash instead of SNAPSHOT. we can add generating this file to the generator along with containerizing the generation.
There was a problem hiding this comment.
It's auto-generated, based on whatever the version here is pointing at. I locally updated that to point at the latest snapshot build. Trouble is, 2.3.0 isn't released yet, and updating that file to point at 2.3.0-SNAPSHOT requires you to checkout & build swagger-codegen locally to run the code generator. As far as I know, you can't point at a specific commit hash anyhow.
There was a problem hiding this comment.
When we create containers for gen repo, they would checkout either a released version or specific commit of swagger-codegen and build using that. There, we can modify this file to record the commit it used to generate the code. It is a design I had in mind but if you have a better suggestion, let me know.
There was a problem hiding this comment.
Specific commit or release version sounds best - how were you going about pointing at the specific commit? If that can be set externally to the pom.xml, pointing at -SNAPSHOT will use the codegen at that commit.
There was a problem hiding this comment.
I wonder if we can set commit hash string instead of -SNAPSHOT in pom.xml file (e.g. 2.3.0-f9d44a838b26f537ea65fd36b5eeb6d07fb5d39f). It is allowed in semver. The script that suppose to build the container can use that specific commit or a released version otherwise.
There was a problem hiding this comment.
To supply a version in the pom.xml that depends on the git commit we'd have to change how swagger-codegen is built. The version specified here is resolved by maven, not our build script, unfortunately. If our automation did this, it might get messy and interfere with users local development environments since to pull a -SNAPSHOT release your machines local maven repo is used.
It might make sense (for now in documentation only) require the latest @ HEAD version of swagger-codegen to be checked out & built locally each time the client generation is run (until 2.3.0 is released). This should technically agree with semver, given that the maintainers of swagger-codegen are diligent in segmenting changes to each release branch by feature/bug-fix/breaking-change/etc...
There was a problem hiding this comment.
The solution was about a build container. It should not interfere with local development environment. Basically that is my suggestion for build-gen-contianer.sh for a specific language:
- Read pom file of that language and extract swagger-codegen version from it.
- If it is not a final release (has - in it), parse it and extract commit hash from it. (if it said SNAPSHOT then head would be the commit hash).
- Build a container by checking out that specific commit (or a release version or head).
- Copy and then modify language pom.xml into the container to replace the commit hash (if exists) with "-SNAPSHOT"
- Setup rsync's and generate the client using this container.
There was a problem hiding this comment.
(btw this is not blocker for this PR, will move the discussion to kubernetes-client/gen#5)
0866c34 to
f9d44a8
Compare
|
please separate generated and manual changes (if any) in different commits |
|
Will do |
f9d44a8 to
17c06d7
Compare
|
Done |
|
This LGTM, I'll wait for @mbohlool to give it one final look. |
| .gitignore | ||
| git_push.sh | ||
| # Remove this once swagger-codegen 2.2.3 is released and we update. | ||
| # Remove this once swagger-codegen 2.3.0 is released and we update. |
There was a problem hiding this comment.
Do we use the HEAD of swagger-codegen for this PR? In that case, why we still have this line?
There was a problem hiding this comment.
HEAD of swagger-codegen is technically still behind 2.3.0 since it hasn't been released yet. I'm realizing the line below I left filenames commented-out that shouldn't be overwritten until that PR is merged.
There was a problem hiding this comment.
What I meant was the comment is not useful anymore if we are using the latest swagger-codegen code to generate this. e.g. we don't need to wait for 2.3.0 to get this feature and we should not ignore any file here (as our change is already in HEAD).
I see all those files are commented out here anyway, so we don't ignore them in generation? Even ApiClient that we are manually editing bellow?
There was a problem hiding this comment.
The change is not merged yet, which is why those files are in that ignore list. Once 2.3.0 is out (or the PR is merged) it will be safe to regenerate the files.
| @@ -0,0 +1 @@ | |||
| 2.3.0-SNAPSHOT No newline at end of file | |||
There was a problem hiding this comment.
(btw this is not blocker for this PR, will move the discussion to kubernetes-client/gen#5)
17c06d7 to
c9b985f
Compare
c9b985f to
4cec7b9
Compare
| // Setup authentications (key: authentication name, value: authentication). | ||
| authentications = new HashMap<String, Authentication>(); | ||
| authentications.put("BearerToken", new ApiKeyAuth("header", "authorization")); | ||
| authentications.put("BasicAuth", new HttpBasicAuth()); |
There was a problem hiding this comment.
BTW because authentications is private, and there is no way to modify it we (for now) need to make this edit in place. I'll make an edit in swagger codegen that allows us to specify custom authentications.
There was a problem hiding this comment.
Follow up on my previous comment, if we are manually editing ApiClient.java, we should add it to the ignore list and remove it when the upstream PR is merged.
There was a problem hiding this comment.
There was a problem hiding this comment.
Oh sorry I had locally staged changes that weren't pushed, h/o
There was a problem hiding this comment.
Nvm they are pushed, you're commenting on an old commit.
|
LGTM. |
No description provided.