Use BUNDLE_LOCKFILE when detecting the lockfile

[Thomascountz]

If a workflow sets BUNDLE_LOCKFILE, setup-ruby still assumes ${BUNDLE_GEMFILE}.lock or gems.locked. That means it can read the wrong BUNDLED WITH version, fail to enable deployment mode because it checks the wrong lockfile path, and/or generate a cache key from the wrong lockfile.

Bundler added BUNDLE_LOCKFILE support in PR #9059

[eregon]

Looks good, thank you

[ntkme]

Given that we have a fs.existsSync check for BUNDLE_GEMFILE or its default value Gemfile that would thrown an exception if missing, we should probably have fs.existsSync check for BUNDLE_LOCKFILE if it's explicitly set. In this case, unlike the check for gemfilePath, we should not check existence of Gemfile.lock because it's optional.

[eregon]

I'm not following, the code is fine as-is, no? Because the lockfile is always optional.

[ntkme]

If you explicit define an environment variable for it, most likely it means you want to explicitly use that file. In that case if the file specified in the variable does not exist and we treat it as optional, wouldn’t that be confusing?

[eregon]

Since it's a variable recognized by Bundler people might use it independently of setup-ruby so I think it's fine and not something we should check.

But, that makes me think probably this needs to be part of the cache key.

[eregon]

lockFile is already in computeBaseKey, so all good