Use robust path when reading .ruby-version

[Copilot]

What does it do?

Addresses https://github.com/wordpress-mobile/release-toolkit/pull/677/files#r2583457311

The .buildkite/shared-pipeline-vars script hardcoded the Ruby version instead of reading from .ruby-version. This change uses ${BASH_SOURCE[0]} to construct a location-independent path to .ruby-version, ensuring the script works regardless of the sourcing directory.

Before:

export RUBY_VERSION="3.2.2"

After:

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
export RUBY_VERSION="$(cat "$SCRIPT_DIR/../.ruby-version")"

Checklist before requesting a review

• Run bundle exec rubocop to test for code style violations and recommendations. (Shell script change only)
• Add Unit Tests (aka specs/*_spec.rb) if applicable. (No test infrastructure for shell scripts)
• Run bundle exec rspec to run the whole test suite and ensure all your tests pass. (Shell script change only)
• Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section. (Internal tooling change)
• If applicable, add an entry in the MIGRATION.md file to describe how the changes will affect the migration from the previous major version and what the clients will need to change and consider. (Not applicable)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Use robust path when reading .ruby-version</issue_title>
<issue_description>See https://github.com/wordpress-mobile/release-toolkit/pull/677/files#r2583457311

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Use robust path when reading .ruby-version #679

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[dangermattic]

	1 Warning
⚠️	Please add an entry in the CHANGELOG.md file to describe the changes made by this PR

Generated by 🚫 Danger

[mokagio]

Confirmed that the interpolation remains correct, as CI is using 3.2.2:

@AliSoftware @iangmaia keen to hear what you think of:

• Using .ruby-version as the single source of truth
• The path juggling

[AliSoftware]

I'm ok with using .ruby-version as source for that.

The path juggling feels a bit ugly, but iinm that's how it's supposed to be done in bash (i.e. I've seen this pattern elsewhere in various occasions), as it covers the case of BASH_SOURCE[0] being a relative path with arbitrary depth—i.e. the reason it does cd $(dirname "${BASH_SOURCE[0]}") && pwd is to cover cases like if ${BASH_SOURCE[0]} is just ./shared-pipeline-vars, where dirname will return . and the ./../.ruby-version will still work, while doing REPO_ROOT=$(dirname "$(dirname "${BASH_SOURCE[0]}")) would not work because the outer dirname . would not return .. but just ., so would not go up one level as that upper level is not part of the relative path…

Another option would have been to leverage git rev-parse --show-toplevel to get a variable pointing to the root of the repo, instead of relying on ${BASH_SOURCE[0]}. But I feel like it's more idiomatic for the shared-pipeline-vars to fully rely on bash-isms only and not rely on the git command to do those path operations (and thus not rely on if that script is run in the context of a git repo or not), to keep things conceptually isolated.

[mokagio]

I was surprised to see a request to approve a workflow in the checks:

I also did not like there being an approve button without a list of workflows that required approval.

I checked the Actions tab and found the workflow in question:

I then clicked the button. The workflow did not run and was instead skipped, I guess because the run triggered by me marking the PR as ready for review superseded it.