test rails 5.0

[mtparet]

• update rubies to last version
• test rails 5.0

[iNecas]

I suppose we should get it also fixed at the same PR, right?

[mtparet]

Indeed this is the goal. Also this will permit to check PRs/issues (and perhaps we could merge these in this one if needed) against Rails 5. #465 #481 #479 #473

[iNecas]

Ok, let's get this in to make the train moving

[iNecas]

The only thing is all the tests are failling on all rails versions now

[mtparet]

Yes, tests should passed before merging. (some works are required)

[raisin]

Rails 5.x.x.x has introduced several changes that impact apipie compatibility. 11 compatibility issues need to be resolved before apipie will pass all the specs that have been written.

The following (forked) branch resolves 8 of these 11 issues. It isn't the most elegant code, but it illustrates how to fix these 8 issues.

https://github.com/raisin/apipie-rails/tree/raisin-rails-5.x-compatibility

If no one is actively working on this, I can improve the code and make it worthy of a pull request. However, a decision needs to be made on how to handle Rails version based forks in the code. Should one gem handle all Rails versions. Or, should a separate gem be created to handle Rails 5.x.x.x?

Here is a breakdown of the remaining 3 issues, which correspond to 7 failing specs.

For 2 of the remaining 3 issues, I wrote comments describing the problem within the branch linked above. These 2 issues correspond to 2 failing specs each for a total of 4 failing specs.

1. One issue is caused by the failure of api!. Using the equivalent version that does not grab information from routes.rb fixes these two specs. Since work was underway in Fix route discovery with api! for Rails 5 #465, which was merged, I didn't attempt to fix this.
2. The other issue is caused by the use of the get parameter :method. :method cannot be used as a url parameter in Rails since it is a reserved keyword. Fixing this problem may require renaming a large number of variables; so, it would be best for a maintainer to look at this problem.

That leaves 1 issue that corresonds to 3 failing specs.
spec/controllers/users_controller_spec.rb:295 represents the problem. I worked on this issue but didn't make progress. It would help to get feedback from someone familiar with apipie internals. It appears that a broadcast is made to multiple threads. It is unclear why that's being done. This spec checks that nested parameters are properly invalidated. Is the recursive check of nested parameters using multiple threads?

[mtparet]

Closing in favour of #527

[iNecas]

Aand it has been merged, the release will follow over the weekend