Skip to content
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

I think hashie is causing some of these CI failures. #58

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bertrama
Copy link

I think this will fix:

1) Error:
ConfigurationReorderTest#test_can_reorder:
ActionView::Template::Error: undefined method `remove_section' for #<Array:0x0000000a721a28>

@jrochkind
Copy link
Member

That was some too-tricky code I put in to make something that looks just like an Array but also has a remove_section method.

It looks like it passed CI, and started failing with no code changes at all -- but probably a new version of hashie.

hashie is also kind of too-clever code.

Ah, the too-clever code of our youth! I'll try to look over it and merge it if @kevinreiss doesn't get to it. Kevin, you/your team still theoretically holding down the pilot's seat here?

Thanks for your work @bertrama !

@jrochkind
Copy link
Member

Ah, I see you locked to an older version of hashie that doens't break umlaut. I'd rather fix the issue to keep working with the new hashie if possible, but that'll take some looking into.

A local workaround for anyone using Umalut, is just lock hashie to the known working version in your local app Gemfile.

@bertrama
Copy link
Author

I agree, that's a better route to take. I recall checking it out for a little bit, but when I saw that hashie 3.4.5 and 3.4.6 were released on the same day, I figured I'd come back and see if they discovered they had introduced other bugs.

@kevinreiss
Copy link
Contributor

Hi, sorry to miss this PR until now. I also agree it would be better to track down the problem rather than pin the gem to an earlier Hashie release. Quick question about the versions of Ruby Travis CI is checking, should ruby 1.9.3 still be listed there? Looks like there is a gem in the project that isn't compatible with versions of ruby pre 2.0.

mime-types-data-3.2016.0521 requires ruby version >= 2.0, which is incompatible

@jrochkind
Copy link
Member

re: 1.9.3: Yeah, mime-types-data. Earlier versions are compatible with 1.9.3 and work just the same, so Umlaut will still work fine with 1.9.3, those people will just have to make sure to pin to an earlier version in their Gemfile.

As far as the CI, in other projects I've done complicated things where there's logic in the Gemfile (not gemspec, Gemfile, just for Travis and development) that uses an ENV variable to determine what ruby it's running under, and pins to an earlier version of mime-types-data if it's 1.9.3.

Or you could just mark 1.9.3 as "allowed failure" in Travis, and say future versions of Umlaut don't really support 1.9.3, which I think would not be unreasonable, 1.9.3 is end-of-lifed.

As far as the hashie issue -- the best solution is probably changing the implementation of that silly remove_section API so it's no longer trying to live extend an object instance, which is what's conflicting with Hashie. Or really getting rid of that API entirely, but I guess that would be backwards incompatible. In retrospect, trying to make an object in config that looks just like an Array but also has a remove_section method was probably ill advised, as perhaps was using Hashie/confstruct in the first place.

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.

None yet

3 participants