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

Several minor fixes in the Go client code generator for Camelization of elements #2289

Merged
merged 1 commit into from
Mar 2, 2016
Merged

Conversation

neilotoole
Copy link
Contributor

See issue #2285 for more details. This fix has been verified locally against a known good swagger file, and the generated client tested against just a handful of operations, so quality is not assured. From my quick look around there doesn't appear to be a Go test harness, I think that's something that we many need to work on. Apologies for any violations of style etc, feel free to edit as needed.

@wing328
Copy link
Contributor

wing328 commented Mar 2, 2016

@neilotoole yes, thank for the PR. Totally agree that we should have some test cases for Petstore GO API client.

I created a task for tracking here: #1948

If you've cycle, we would appreciate your contribution on that.

@wing328 wing328 added this to the v2.1.6 milestone Mar 2, 2016
@neilotoole
Copy link
Contributor Author

@wing328 Hopefully I'll have some free cycles coming up in the next few weeks. Do you have a general strategy for dealing with test harness runtimes? (Apologies, I haven't yet had a good look around the rest of the codebase). Given that this test harness would require the installation of the Go runtime, perhaps it should be done in a container? Or any other thoughts?

wing328 added a commit that referenced this pull request Mar 2, 2016
Several minor fixes in the Go client code generator for Camelization of elements
@wing328 wing328 merged commit 336d80c into swagger-api:master Mar 2, 2016
@wing328
Copy link
Contributor

wing328 commented Mar 2, 2016

For testing, travis-ci does not support multiple languages so we've to install the lang/package manually if it's required by the test.

As an example, for ObjC/Swift, the tests are not run by the CI so currently I've to manually run the tests when reviewing changes related to ObjC/Swift.

@neilotoole
Copy link
Contributor Author

Hmmmn... well, in this era (so far! so soon!), any CI process worth its salt should allow one to kick off a container to execute tests? Concourse CI for example. With all the different runtime harnesses that codegen needs to support, this seems almost a determining factor for CI selection?

@wing328
Copy link
Contributor

wing328 commented Mar 2, 2016

I did reach out to other CI providers and hopefully they've better (and free) solution for our special case.

@neilotoole
Copy link
Contributor Author

Best of luck with that! Let me know if I can help. Containers are really the only way to go if you'd like to (ultimately) have full end-to-end test harnesses for each of the supported languages. It's effectively physically impossible to do it otherwise, and that's really what we should be aiming for.

@wing328
Copy link
Contributor

wing328 commented Mar 2, 2016

Totally agree. I'll share the update once I've more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants