Improve go.mod support in generator #1661
Conversation
This improves the `go.mod` support added in go-swagger#1636 by adding support for targets not at the module level. Imagine you generate code like this: ```bash $ swagger generate client --name my-api --target ./pkg/api ``` Then it would assume `go.mod` is under `pkg/api` and not detect that go modules are used. The fix is to walk up the directory to find the first occurance of `go.mod` and assume that as the module base URL. Signed-off-by: Mikkel Oscar Lyderik Larsen <m@moscar.net>
|
I don't understand why the build is failing, I can run the tests fine locally. Any ideas if it's related to my changes? |
|
Looks related to some previous changes I made... I have to investigate there: a bug did sneak in undetected |
|
I suggest as a temporary workaround to pass your PR to comment the "Parallel()" statement here I assume my latest attempt to improve this did introduce some smelly behavior. You could try this and see if your pr passes. I'll try to fix things up later on. |
Signed-off-by: Mikkel Oscar Lyderik Larsen <m@moscar.net>
Codecov Report
@@ Coverage Diff @@
## master #1661 +/- ##
==========================================
- Coverage 80.31% 80.21% -0.11%
==========================================
Files 38 38
Lines 7387 7404 +17
==========================================
+ Hits 5933 5939 +6
- Misses 992 1002 +10
- Partials 462 463 +1
Continue to review full report at Codecov.
|
|
@fredbi commenting out the parallel config did make the build run successfully. |
|
Found the concurrency bug in unit test. Going to fix it and s 9341 pecifically test for this... |
This improves the
go.modsupport added in #1636 by adding support fortargets not at the module level.
Imagine you generate code like this:
Then it would assume
go.modis underpkg/apiand not detect that gomodules are used. The fix is to walk up the directory to find the first
occurance of
go.modand assume that as the module base URL.