bundler-cache: true is a great feature!
But when I'm using it, the job logs seem to lack the list of gems that were actually installed, even if expanded.
This is for a project that is a gem so does not have Gemfile.lock checked into repo.
When using similar functionality on travis (which I'm moving from), even when caching the bundle, you could still expand the logs to see actual bundler install output with individual gems, that might just have "Using" lines since theywere all installed something like:
...
Using rspec-support 3.9.3
Using rspec-core 3.9.2
Using rspec-expectations 3.9.2
Using rspec-mocks 3.9.1
Using rspec 3.9.0
Using rspec-rails 4.0.1
Using rubyzip 2.3.0
...
I have found this can be invaluable for debugging a build, or comparing why one build might be behaving differently to another -- you can look at the logs to see exactly which versions of all dependencies are installed. It's not common for me to expand logs of the build at all, but when I do this is the most common thing I'm looking at.
However, with setup-ruby with bundler-cache: true, it looks like:
I can't see the actual list of gems installed. I'm not sure if this was intentional or a side effect of how you're doing things, don't totally understand what's going on.
But I find it a loss!
I suppose a workaround could maybe be uploading the produced Gemfile.lock as an artifact, since this could also be used to see exactly what version of all dependencies is installed.
Actually... as I think about how this bundle cache appears to be working... if it's actually skipping the entire bundle install and just using cached install if cache key matches... now I realize without checking Gemfile.lock into repo, does that mean I will not get new versions of dependencies that have become available on rubygems unless my Gemfile/gemspec itself changes? Oh no, that may mean this feature is unsuitable for me entirely.
bundler-cache: trueis a great feature!But when I'm using it, the job logs seem to lack the list of gems that were actually installed, even if expanded.
This is for a project that is a gem so does not have Gemfile.lock checked into repo.
When using similar functionality on travis (which I'm moving from), even when caching the bundle, you could still expand the logs to see actual bundler install output with individual gems, that might just have "Using" lines since theywere all installed something like:
I have found this can be invaluable for debugging a build, or comparing why one build might be behaving differently to another -- you can look at the logs to see exactly which versions of all dependencies are installed. It's not common for me to expand logs of the build at all, but when I do this is the most common thing I'm looking at.
However, with
setup-rubywithbundler-cache: true, it looks like:I can't see the actual list of gems installed. I'm not sure if this was intentional or a side effect of how you're doing things, don't totally understand what's going on.
But I find it a loss!
I suppose a workaround could maybe be uploading the produced Gemfile.lock as an artifact, since this could also be used to see exactly what version of all dependencies is installed.
Actually... as I think about how this bundle cache appears to be working... if it's actually skipping the entire
bundle installand just using cached install if cache key matches... now I realize without checking Gemfile.lock into repo, does that mean I will not get new versions of dependencies that have become available on rubygems unless my Gemfile/gemspec itself changes? Oh no, that may mean this feature is unsuitable for me entirely.