Fix github builds

[iftheshoefritz]

• Ignore errors in bundle install && yard gems step

Ruby 3.1.0 doesn't seem to mix well with yard gems and exits with code 1, causing the entire build to fail. Ignore this since the tests still seem to pass.

• Loosen bundler dependency for compatability with setup-ruby@v1

The actions workflow appears to be failing because setup-ruby isn't compatible with bundler 2.3. I'm sure there is a more "correct" way of working around this, I don't know github actions at all.

However it seems ok to loosen the dependency on bundler to '~> 2.2' to get the builds passing again.

[iftheshoefritz]

I see that 2.7 and 3.0 builds are now having problems, which I don't see locally :/

[iftheshoefritz]

CI is behaving as if the yard installed in the "install Rails 5/6/7" steps is wiped out. This line in the docs makes it look as though the actions are failing because of multiple bundler calls:

"If you install any new gems, or change a version, the cache will be invalidated and bundler will do a fresh install"

(the evidence does not completely fit because I'm not sure why the last rails version tested wouldn't be preserved ... I'd expect one of the rails versions to pass if this was true)

[alisnic]

"install Rails 5/6/7" steps is wiped out

maybe let's try to run integration tests for a specific version only? try installing gems only for rails5 and run spec/rails5_spec.rb in github actions and let's see what happens

[alisnic]

First possible cause from my testing - ruby@setup-ruby@v1 step saves gems to vendor/bundle in project root (which when we test locally is not the case), but we install gems in sample apps explicitly and use a different gem root. Will try to use the same path

[alisnic]

I wasn't able to fix this from my testing, but I think the problem is 100% in vendored bundler path.

@iftheshoefritz to speed up your testing, I recommend you use https://github.com/nektos/act. You can trigger PR workflow locally via act pull_request and not wait for Github to run the changes.

I will try to debug more these days

One thing worth exploring is install ruby by hand without using setup-ruby and see what happens

[iftheshoefritz]

@alisnic thanks for the tip about act. Sadly it runs through the steps really slowly for me, most especially running yard gems. One thing that is really helpful is running act -v gives verbose output on what each action is doing. When I have time to go through that in detail I'm sure I'll learn some useful things.

Currently in this branch I added an action that allows you to SSH into the container where the actions are being run. Things I notice from there:

• default ruby setup for root installs gems to ..../vendor/bundle (overriden BUNDLE_PATH in .bundle/config)
• bundle in spec/rails5 installs gems to somewhere else: /opt/hostedtoolcache/.... (clutching at straws here, but I wonder if this path is dictated by the bundler-cache: true option we're using)
• ~/.gemrc is set up to install gems with --no-document

When I run bundle exec rspec spec/solargraph-rails/rails5_spec.rb from the root I get a warning from solargraph about cannot find activesupport-5..., falling back to activesupport-7...

I tried overriding the BUNDLE_PATH in the spec/rails5 directory, and after I did that I stopped getting the warning from solargraph. However spec/rails5 still failed with the same error.

Removing the --no-document from ~/.gemrc didn't seem to make a difference. I guess running yard gems does everything that --no-document skips.

[alisnic]

@iftheshoefritz I was able to fix the builds in https://github.com/iftheshoefritz/solargraph-rails/pull/46, please take a look

[alisnic]

Fixed in https://github.com/iftheshoefritz/solargraph-rails/pull/46