Reproducible build with appriasal

[bolshakov]

README suggests not to commit lockfiles into VCS.

When using Appraisal, we recommend you check in the Gemfiles that Appraisal generates within the gemfiles directory, but exclude the lockfiles there (*.gemfile.lock.) The Gemfiles are useful when running your tests against a continuous integration server such as Travis CI.

But if you don't commit lockfiles, your build may failed occasionally. I understand the idea of building against latest versions, but build should not fail if no changes done in your project.

What do you think?

[drwl]

For my use case - I check in the *gemfile.lock because it's possible to introduce bugs if appraisal updates a gem or its dependency. This usually happens when the ~> operator is used.

[nbibler]

That's kind of the point, isn't it? If your dependencies are defined too loosely and you get intermittent failures from dependency changes, you need to re-evaluate your trust in those sub-libraries or your version allowance leniency for that library.

Perhaps they're not following Semantic Versioning so you really shouldn't be using ~> (Rails! 👀). Or perhaps they do follow Semantic Versioning but the library author introduced an inadvertent bug in a patch or minor release (which should be reported and your Gemfile should reflect the avoidance of that version, gem 'lib-with-bad-release', '~> 2.0', '!= 2.1.3').

Appraisal is generally acting as someone or something new starting your application or library and doing a fresh build, today. What would happen? How would the application behave? Did you account for changes to your dependencies properly? How does your app behave when those dependencies do change?

You could always hardcode to a specific version if you really don't want them changing but are unwilling to update your gemspec or Gemfile to properly reflect that.

appraise 'name' do
  gem 'rails', '= 5.2.3'
end

[bolshakov]

I agree, defining dependencies is tricky exercise. But I'm talking about reproducible build. That happened to me really often -- after fixing a bug, build fails because of newer dependencies.

We should update dependencies somehow and test against them. But when Gemfile.lock is not in a repository, we are doing this unexpectedly.

[nbibler]

Based on how I'm understanding your problem, I'm guessing that you just need to better fill out your Appraisals file to be strict about all of the dependencies you care about (and presumably not about those that you're okay with changing, if any). Or strictly define your dependencies in your Gemfile or gemspec. Any of those approaches would address your concerns.

However, at that point, I'm not really sure what Appraisal is doing for you. You would really just have a handful of fully-defined, static Gemfiles at that point which always have the same lockfiles (or very-near in the case of distant sub-dependencies). I'm not sure I see what the point of using Appraisal would be in that scenario. If you want to be that controlling, just hand-roll n number of Gemfiles that you want to test against - with whatever names you want - run Bundler to create the lockfiles, and commit them all to the repository. Then manually manage them when you want to update them (explicitly update one of them and explicitly run bundler to save the new lockfile).

Maybe I'm just confused about your use case?

[nickcharlton]

I might be missing something here, but @nbibler is explaining what I'd do.

I'm going to close this for now, but please reopen if you'd like to go into more depth.