Skip to content

Adds support for grape >= 1.2 #717

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

Merged
merged 7 commits into from
Oct 29, 2018
Merged

Adds support for grape >= 1.2 #717

merged 7 commits into from
Oct 29, 2018

Conversation

myxoh
Copy link
Member

@myxoh myxoh commented Oct 23, 2018

This PR is required after: ruby-grape/grape#1803
to make sure that grape-swagger is compatible with grape after the breaking changes introduced in 1.2.0

Because of the nature of the changes in the grape gem, this version won't be compatible with prior versions of grape

@coveralls
Copy link

Coverage Status

Coverage decreased (-44.004%) to 55.204% when pulling 06f86ac on myxoh:support1.2 into 95d5e35 on ruby-grape:master.

@coveralls
Copy link

coveralls commented Oct 23, 2018

Coverage Status

Coverage increased (+0.006%) to 99.213% when pulling d67981a on myxoh:support1.2 into 224c5f2 on ruby-grape:master.

@myxoh
Copy link
Member Author

myxoh commented Oct 23, 2018

Not sure how to handle the fact that this is dependant on the other code being merged. I've tested this locally manually using the branch and it was working

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should try to make this backward compatible. The only difference is the class name being extended, so you should be able to do this with an if defined?(Grape::API::Instance) or something like that.

You need a spec for next version of grape regarding mounting the API twice. What happens to swagger in that case?

Gemfile Outdated
@@ -6,7 +6,7 @@ ruby RUBY_VERSION

gemspec

gem 'grape', case version = ENV['GRAPE_VERSION'] || '~> 1.0'
gem 'grape', case version = ENV['GRAPE_VERSION'] || '~> 1.2'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave this at 1.0 for now, but add another entry to .travis.yml with the branch, so for example

when 'INSTANCE'
 { git: '...', branch: '...' } # your own PR branch here
when 'HEAD'
  ...

UPGRADING.md Outdated
@@ -1,5 +1,9 @@
## Upgrading Grape-swagger

### Upgrading to >= 0.32.0

This version is *only* compatible with grape >= 1.2.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add some info on why, link to the other PR, add a link.

@myxoh
Copy link
Member Author

myxoh commented Oct 25, 2018

I've addressed the issue of making swagger compatible with previous versions of Grape.
I've also added a test that covers re-mounting if the version of grape is higher than 1.2

@dblock
Copy link
Member

dblock commented Oct 25, 2018

This looks great. We can keep this moving once the Grape PR is merged.

@dblock
Copy link
Member

dblock commented Oct 27, 2018

@myxoh Now that ruby-grape/grape#1803 got merged this can be updated to build against HEAD only

Makes swagger backwards-compatible again


Adds a test that covers re-mounting with configuration


Describes changes on this PR


Removes custom branch from build process
@dblock
Copy link
Member

dblock commented Oct 29, 2018

Looks like a rubocop failure. Lock it at 0.59.2 or upgrade to 0.60.0 and rubocop -a ; rubocop --auto-gen-config?

@myxoh
Copy link
Member Author

myxoh commented Oct 29, 2018

Thanks @dblock . Addressed.
By the way, I've sent you an e-mail regarding the request on the other thread. Let me know if you require anything else.

Gemfile Outdated
@@ -26,7 +26,7 @@ group :development, :test do
gem 'rake'
gem 'rdoc'
gem 'rspec', '~> 3.0'
gem 'rubocop', '~> 0.59', require: false
gem 'rubocop', '~> 0.60', require: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is OK for now, but really should just be a specific version, because each new release (eg. 0.61) will produce new errors/warnings.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure whether it is desirable to lock the gem, rather than tackle the new errors / warnings as they come.
If you still feel I should lock this to a version, I'll do that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got this in #719.

We lock rubocop because it's otherwise a moving target. Yesterday ~> 0.59 resolved to 0.59, but today it resolved to 0.60, producing new errors. So the same code built green yesterday but fails to build today, which is not desirable.

New errors and warnings should totally be tackled, but not in the way of feature/fix work :)

Copy link
Member

@LeFnord LeFnord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work … thanks

CHANGELOG.md Outdated

#### Features

* Your contribution here.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please re-add it again, same for line 9

Gemfile Outdated
@@ -26,7 +26,7 @@ group :development, :test do
gem 'rake'
gem 'rdoc'
gem 'rspec', '~> 3.0'
gem 'rubocop', '~> 0.59', require: false
gem 'rubocop', '0.60', require: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't lock it, minor rubocop updates are much easier to handle then big ones

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock Could you guys agree on a decision? I'm happy either way as I see both views as valid, but I don't want to step over either of you

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets take it to #719

@@ -1,5 +1,5 @@
# frozen_string_literal: true

module GrapeSwagger
VERSION = '0.31.2'
VERSION = '0.32.0'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revert, will be done on next release

@LeFnord
Copy link
Member

LeFnord commented Oct 29, 2018

thanks @myxoh … please also add a travis entry

@myxoh
Copy link
Member Author

myxoh commented Oct 29, 2018

@LeFnord regarding adding a travis entry. I'm pressuming you mean against 1.12, however, that was not released yet, it's still on HEAD. Would you reckon we should wait until that's released and then add it to the matrix?

@LeFnord
Copy link
Member

LeFnord commented Oct 29, 2018

ok @myxoh

@LeFnord
Copy link
Member

LeFnord commented Oct 29, 2018

again … great work @myxoh … will mörge it, after specs are green 😄

@LeFnord LeFnord merged commit 2457215 into ruby-grape:master Oct 29, 2018
LeFnord pushed a commit to LeFnord/grape-swagger that referenced this pull request Feb 9, 2019
* Adds support for grape >= 1.2


Makes swagger backwards-compatible again


Adds a test that covers re-mounting with configuration


Describes changes on this PR


Removes custom branch from build process

* Upgrades Rubocop and autofixes indentation

* Locks rubocop version to 0.60

* Rollbacks version bump

* Removes HEAD from allowed failure
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants