I have really simple Gemfile:
source 'https://rubygems.org'
gem 'stripe-ruby-mock',
github: 'mnin/stripe-ruby-mock',
require: 'stripe_mock',
ref: 'b6446fb5ae2b14b6703554cbea4ebd466e4f3c47'
When I run bundle command to install this gem I get this error:
root#6bcff6bf3997:/app# bundle
The git source `git://github.com/mnin/stripe-ruby-mock.git` uses the `git` protocol, which transmits data without encryption. Disable this warning with `bundle config git.allow_insecure true`, or switch to the `https` protocol to keep your data secure.
Fetching git://github.com/mnin/stripe-ruby-mock.git
fatal: Could not parse object 'b6446fb5ae2b14b6703554cbea4ebd466e4f3c47'.
Revision b6446fb5ae2b14b6703554cbea4ebd466e4f3c47 does not exist in the repository git://github.com/mnin/stripe-ruby-mock.git. Maybe you misspelled it?
But I can visit the commit's page on Github using this link https://github.com/mnin/stripe-ruby-mock/commit/b6446fb5ae2b14b6703554cbea4ebd466e4f3c47.
So how can I the gem using this commit's hash?
That commit is not reachable from any branch or tag. For that reason, when you clone the repo from GitHub (which Bundler does under the hood), your local copy will not have that commit.
Thus, you can't use it.
On GitHub, you can see that this commit is not reachable as it doesn't list any branch or tag that contains it:
Compare that to the parent commit, which lists as being reachable from master:
Note that orphaned commits would get garbage collected by Git eventually. GitHub though doesn't do that as there might be references to particular commits.
Try not to use forked gem if possible. But if you need to lock a forked version, make sure you own the fork. Fork the forked branch, merge it to your own repo's main branch, and then just use that repo in your gemfile.
Related
CircleCI install dependencies error:
Your bundle is locked to my_cool_gem (0.7.2), but that version could not be
found in any of the sources listed in your Gemfile. If you haven't changed
sources, that means the author of my_cool_gem (0.7.2) has removed it. You'll
need to update your bundle to a version other than my_cool_gem (0.7.2) that
hasn't been removed in order to install.
Screenshot of CircleCI output:
CircleCI can't find a gem that I published to GitHub Packages, yet I have no such problem in local development.
I have qualifying versions of RubyGems and Bundler, as per GitHub's docs - https://docs.github.com/en/free-pro-team#latest/packages/guides/configuring-rubygems-for-use-with-github-packages - and I believe I have followed the instructions to publish and use said published gems... and, again, usage works locally but fails in CircleCI...
RubyGems version:
-bash> gem --version
3.0.9
Bundler version:
-bash> bundle --version
Bundler version 1.17.3
Gemfile:
source 'https://rubygems.org'
source 'https://rubygems.pkg.github.com/my_cool_org'
gem 'my_cool_gem', '0.7.2'
Note that I have also tried:
source 'https://rubygems.org'
source 'https://rubygems.pkg.github.com/my_cool_org'
source 'https://rubygems.pkg.github.com/my_cool_org' do
gem 'my_cool_gem', '0.7.2'
end
Try running bundle update my_cool_gem if it modifies Gemfile.lock that should fix it.
Have you verified that it's actually still available at the source? I know you said it works locally, but that could be because of local cached versions of the gem. Bundle won't try to install something that's already there.
You might be able to verify this by uninstalling it locally and running bundle install again.
Ensure that you've correctly set the environment variable for authenticating with rubygems.pkg.github.com.
(Though the variable may be set, the value may be incorrect - as was the case for me.)
Interesting, sounds like a image bug. What happens if you try to list all available versions of your gem? gem search ^gem_name$ --all?
Have you tried to force update beforehand? sudo gem update --system
For me, the problem was that access tokens was different on local machine and on CI. And the key on CI was valid, but it had no permission for specific repository containing requested gem.
Despite Github provides single registry per organization, gems are associated with company's repositories. And packages within registry will be visible or invisible depending on permissions to these repositories that access tokens have. For example, user can have access to some repositories of organization and don't have to others — if using that user's personal access token, only gems associated with permitted repositories will be visible. Others will be hidden, so the error is "that version cannot be found".
I ran into this again, and this time I could not solve it with the solution I used last time, and no other solution worked either, so instead I chose to temporarily work around the issue by placing a copy of the gem in question directly into my app (a process known as "vendoring"; see this, this, and this):
gem unpack my_cool_gem # note, I actually had to specify the version with -v 0.12.1
mkdir vendor/gems/
mv my_cool_gem-0.12.1 vendor/gems/
In Gemfile, use the :path option rather than :source:
gem 'my_cool_gem', '0.12.1', path: 'vendor/gems'
Then generate Gemfile.lock:
bundle install
I have a gem that is hosted on github and not yet pushed to rubygems, and I added a tag to the master branch of the gem like this:
git tag -a v0.1.0 -m "gem version 0.1.0"
git push origin -tags
and then in a rails application I have on github I edited my gemfile like so:
gem 'your-gem', git: 'git://github.com/your-repo/your-gem.git', tag: 'v0.1.0'
My question is, when I merge in additional changes into the master branch of my gem, my rails application will still point to the last commit before I made the tag? I just want to make sure adding additional changes to the gems master branch will not break anything in the rails app. Thank You
The correct command is git push origin --tags, or git push origin v0.1.0 if you want to push just the one tag, but otherwise yes, your expectation is correct.
See here for more on bundling gems from git repositories:
http://gembundler.com/v1.3/git.html
I have a problem working with a remote repository. I do git clone <URL> just fine.
The problem is when I run bundle. I get loads of errors. Those errors are fixed by using bundle update, as it installs all the gems and then I can run everything fine. The problem is that my Gemfile.lock file gets changed and it comes as a file to be committed in the git repository (which it should not, because it will mess up the remote repository's Gemfile.lock file). Now I cannot push Gemfile .lock to the remote repository as it will break everything. But the strange part was that this Gemfile.lock is not included in the .gitignore file... So any ideas how I can overcome this or could somebody explain to me what exactly is going on ?
When you run bundle, bundler will use the gems that are listed in the Gemfile.lock. bundle update updates the Gemfile.lock to get the latest of all gems listed in the Gemfile while still satisfying all dependencies.
You can run bundle update on a particular gem as well, which will limit the Gemfile.lock changes to dependencies of said gem.
You need to be a little more clear about which errors you are receiving? Are they dependency related? or are you not able to build a gem with native extensions? or something else? are you using gemsets - if not, that might be useful to prevent gem collisions.
Is there really a problem with Gemfile.lock being committed? Are you a contributor to the repository?
Additionally, bundler gets updated every now and then. You may want to update your version of bundler before running bundle.
gem update bundler
I'm still somewhat new to Git and Gemfiles.
I want to upgrade my gems but not all are backward compatible. As such, I want to create a separate branch while I fix my code to be compatible with new gem versions.
If i use git checkout -b mynewbranch and then change Gemfile and start running bundle update, will that confine my gem changes to just that branch?
What's the best approach here?
The versions of gems installed using the bundle install command and the gem versions that will be used is determined by the files Gemfile and Gemfile.lock.
Moving to another branch and updating using bundle update does not interfere with those old files in the old branch. It will update those files on the new branch and install new gems versions to your machine. You can update as much as you want, go back to the old branch and all former versions of gems will be used as expected.
Note that you might need to run commands using bundle exec in case you have multiple versions of same gem on the machine.
I have the following line in my gemfile:
gem 'client_side_validations', :git => "git#github.com:Dakuan/client_side_validations.git", :branch => "master", ref: '2245b4174ffd4b400d999cb5a2b6dccc0289eb67'
The repo it's pointing at is public and I can run bundle install / update locally just fine. When I try to push to Heroku I get the following error:
Fetching git#github.com:Dakuan/client_side_validations.git
Host key verification failed.
fatal: The remote end hung up unexpectedly
Git error: command `git clone 'git#github.com:Dakuan/client_side_validations.git' "/tmp/build_1xa9f06n4k1cu/vendor/bundle/ruby/1.9.1/cache/bundler/git/client_side_validations-56a04875baabb67b5f8c192c6c6743df476fd90f" --bare --no-hardlinks` in directory /tmp/build_1xa9f06n4k1cu has failed.
!
! Failed to install gems via Bundler.
!
! Heroku push rejected, failed to compile Ruby/rails app
Anyone got any ideas about what's going on here?
Use this GitHub URL instead: git://github.com/Dakuan/client_side_validations.git
The git#github.com:… URL is the writable SSH version, which requires authentication with an SSH key connected to a GitHub account that has write access to the repository.
The git://github.com/… URL is the public, read-only version.
Since the gem you're using is in a public GitHub repository, you can also use this shorthand in your Gemfile:
gem 'client_side_validations', :github => 'Dakuan/client_side_validations'
See the Bundler Git documentation for more information.
A late second answer, as I ran into some confusing output from Heroku's build logs which stumped me for a while.
If you have multiple Github hosted gems in your Gemfile, and one of them is inaccessible (in my case, I had accidentally pointed to a private repo of mine), the build logs throw an error like Username not found or Repository not found for all the Github hosted gems - even those that are available.