-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Flatten stopped processing nested directories in v0.26.0 #2743
Comments
Yes, the previous behavior was incorrect, not resolving references from the current document's. Like so: get:
produces:
- "application/json"
responses:
200:
description: "OK"
schema:
$ref: "../definitions/resp1.yml#/Resp1"
500:
description: "Internal server error"
schema:
$ref: "../definitions/errors.yml#/ErrorResponse" I could verify that the specs flatten properly then. |
There appears to be an inconsistency whether the path is resolved from the files directory instead of the root directory. This is what I mean: Using get:
responses:
200:
description: OK
schema:
type: array
items:
$ref: '../user/index.yml#/User' ## this doesn't work
500:
description: OK
schema:
type: array
items:
$ref: './swagger/user/index.yml#/User' ## this works From what you said, the With the |
Running flatten with current master on fixture 2258. Seems to work as expected. cd fixtures/bugs/2258
swagger flatten --format yaml fixture-2258.yaml
2024/01/04 16:47:21 format = yaml swagger: "2.0"
info:
title: Simple API
version: 0.0.0
paths:
/bar:
get:
responses:
"200":
description: OK
schema:
$ref: '#/definitions/user'
/foo:
get:
responses:
"200":
description: OK
"500":
description: OK
schema:
$ref: '#/definitions/errorPayload'
/nested:
get:
responses:
"200":
description: OK
schema:
$ref: '#/definitions/sameFileReference'
definitions:
errorDetailsItem:
description: Represents an item of the list of details of an error.
properties:
code:
type: string
details:
items:
type: string
type: array
message:
type: string
required:
- message
- code
title: Error details item
errorPayload:
properties:
errors:
items:
$ref: '#/definitions/errorDetailsItem'
type: array
required:
- errors
title: Error Payload
model:
properties:
name:
type: string
type: object
sameFileReference:
properties:
name:
type: string
type: object
user:
$ref: '#/definitions/model' The bar.yml document is located in ./swagger/paths I didn't quite understand what you tried to run and what doesn't work specifically. |
Just pushed a tidier couple of examples. Working:
https://github.com/go-swagger/go-swagger/tree/809195a882718648d9647ed12a44ab2071936ba0/fixtures/bugs/_working-example Non-working:
https://github.com/go-swagger/go-swagger/tree/809195a882718648d9647ed12a44ab2071936ba0/fixtures/bugs/_non-working-example |
@mateusbandeiraa thanks for the detailed example. I've been able to reproduce your issue. It looks like this is a valid bug. |
… resolution when SKipSchema * fixes go-openapi#182 * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
This reproduces the $ref issue with relative paths in sibling folders in responses (same applies to parameters, but not schemas). Added a test to verify that: * (i) the invalid path that used to work no longer does * (ii) the valid path that used not to work now does * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
This reproduces the $ref issue with relative paths in sibling folders in responses (same applies to parameters, but not schemas). Added a test to verify that: * (i) the invalid path that used to work no longer does * (ii) the valid path that used not to work now does * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
* fixes go-swagger#2743 This PR onboards the fix to go-openapi/spec#182: * invalid relative path in $ref in schema for parameters or response when SkipSchema=true (flatten use-case) Added a test to assert that the fix works fine with the version update. Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
… resolution when SKipSchema (#183) * fix(expand): parameters & responses should properly follow remote doc resolution when SKipSchema * fixes #182 * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com> * fixed assertion in test for windows paths Signed-off-by: Frederic BIDON <fredbi@yahoo.com> --------- Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
This reproduces the $ref issue with relative paths in sibling folders in responses (same applies to parameters, but not schemas). Added a test to verify that: * (i) the invalid path that used to work no longer does * (ii) the valid path that used not to work now does * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
This reproduces the $ref issue with relative paths in sibling folders in responses (same applies to parameters, but not schemas). Added a test to verify that: * (i) the invalid path that used to work no longer does * (ii) the valid path that used not to work now does * contributes go-swagger/go-swagger#2743 Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
* fixes go-swagger#2743 This PR onboards the fix to go-openapi/spec#182: * invalid relative path in $ref in schema for parameters or response when SkipSchema=true (flatten use-case) Added a test to assert that the fix works fine with the version update. Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
* fixes #2743 This PR onboards the fix to go-openapi/spec#182: * invalid relative path in $ref in schema for parameters or response when SkipSchema=true (flatten use-case) Added a test to assert that the fix works fine with the version update. Signed-off-by: Frederic BIDON <fredbi@yahoo.com>
Problem statement
A certain structure of directories and files worked before v0.26.0 and stopped working after this version. It also does not work with the latest version either.
Swagger specification
https://github.com/nikitakalyanov/go-swagger-test
Steps to reproduce
https://github.com/nikitakalyanov/go-swagger-test
Environment
swagger version: 0.26.0
go version: 1.15.6
OS: Docker image
From the error message it seems that relative paths are now resolved differently. Could we document it somewhere then?
The workaround for now is to flatten the structure manually - i.e. remove the 'paths/' directory and put the mypath1.yml and mypath2.yml files at the root level.
The text was updated successfully, but these errors were encountered: