Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Simplify testing with different versions on Rails #312
referenced this pull request
Jun 21, 2013
I think, I understand the concern of @jferris points int #278 a little more now. And I think I'm leaning towards his arguments of checking in
To address some of the issues @croaky brought up:
There seems to be a mixed amount of popular gems checking in their
This shouldn't be an issue any longer. Since we're using relative paths.
I see this as a valid issue. However, we'd trade stability and consistency of the library, in development, over pollution of the history. It seems like bumping the rails patch version should be a conscious effort. With a little re-factoring we can make it so only the Appraisal's gemfiles get updated, when we choose to run
I don't think there's a perfect answer. What I said before still stands: I defer to those with more experience with library development. That said, here's how I see the pros and cons:
In the 'real world' developers are likely bundling and getting latest versions of stuff unless they have a specific reason not to. As gems that we depend on are updated we'll have to remember to manually update them with a
The ability to reproduce failing tests is certainly nice, but its not much use if what we're testing with isn't actually what our users are using. If someone is incented enough to clone the repo, update the appraisal gemfiles to be in line with what they were using when they hit a bug, and then submit a failing test case, aren't they equally capable of doing this without the appraisal lock files? For users that just want to report a bug, aren't we still going to want to see their Gemfile.lock?
When it comes to git noise, I guess I'm not overly sensitive to it. If lock files are deemed worth keeping and there are lots of checkins of the lock files in order to keep them up to date, so be it.
This is lost if gemfiles are regenerated. We should see if we can add this to appraisal.
This might not actually work, but I just had an idea: What if we had one appraisal file without a checked-in lock file that was only run by Travis (or manually locally, if desired). Would this allow us to catch issues with newer versions of gems while maintaining a clean test suite for gems we know to be good?
I am not sure, how this would work. Can you provide an example?
Here's what might be a vialbe option: Check-in
If the above option seems sane, then lets try it and see what pain points we encounter.
I don't think that's actually the case. I've only worked on a handful of projects where people regularly run
@jferris It still tests against multiple Rails versions. See https://travis-ci.org/thoughtbot/clearance/jobs/8549928 as an example. We just don't need to check the generated gemfiles into version control.