Closed padde closed 2 weeks ago
Instead of relying on a Grape constant that's not supposed to be part of the public interface, just copy it into grape-swagger? Expand CI to use multiple versions of Grape to make sure our compatibility is tested well.
@dblock sure, we could do that and it would vastly simplify the implementation, as we wouldn't have to massage the internal constants as much to make it work for our purposes here.
@dblock looking further into the code that is used from grape here, it seems that there always has been a flaw in the way we retrieve content types in grape-swagger. Grape allows adding user-defined content types. However, if I get this right, grape-swagger never even considered the ones coming from the settings, just the default values from the internal constants that are now causing the issue. Let's continue discussion in https://github.com/ruby-grape/grape-swagger/issues/939#issuecomment-2355343643
Can you try and please turn this into a matrix with two entries: a ruby version and a grape version?
@dblock sure. Honestly, I just expanded on the existing approach to avoid this discussion but I am happily reducing the duplication!
We don't need to test all possible permutations either.
That is a bit vague - which permutations should we test then, if not all? I will for now follow the "wasteful" approach with all permutations, feel free to tell me which ones to remove, if you like.
Running on grape 2.0.2 resulted in the following exceptions:
This is due to internal refactorings in grape as of v2.2.0, specifically https://github.com/ruby-grape/grape/commit/fb67ea99
Fixes #939