Refactor Github actions CI to correctly load gemfile

[kmcphillips]

Problem

The exported env does not persist between steps, so the export BUNDLE_GEMFILE does nothing.

You can see that it loads the current 5.1 for every build step:

Solution

I've refactored the config to use jobs.build.env config instead.

I've cleaned up and refactored a few things too, but that's the major change.

We could use bundler-cache: true but that may not work with the bundler config settings, so I've left it out.

Now we have a new problem

The build appears to have been broken for a while. There are also a ton of deprecation warnings.

I'm going to look into it but will probably need help from owners.

[andyw8]

Thanks @kmcphillips.

fyi @mllemango

[andyw8]

We just recently switched from Travis to GitHub actions in https://github.com/Shopify/shopify_api/pull/808/files so I don't expect much would have broken in that short time.

[andyw8]

(but worth nothing that we previously had allow_failures for when running against AR master).

[mllemango]

I believe the new deprecation messages are coming from activesupport v6.1.0, we used to use v.6.0.3.1 without any problems. Not sure how to approach this other than specifying gem "activesupport", "6.0.3.1" in the Gemfile.

[andyw8]

We can ignore the deprecation messages for the moment, let's fix the time-related issues:

NoMethodError: undefined method `hours' for 24:Integer

It seems to fail inconsistently so may be related to load order and the test randomization.

[andyw8]

Looks like we need to add require 'active_support/time' to session.rb.

[andyw8]

(the intermittent failures may be because GitHub is caching the gem downloads prior to the Rails 6.1 release. But I can't see any way in the UI to to force that to clear.).

[andyw8]

Still not fully sure of the cause of this yet, perhaps there was a transitive dependency on ActiveSupport. But let's make that explicit anyway.

[andyw8]

If #818 is merged then we don't need this.