The Ruby transpiler bridge is just a thin ExecJS wrapper around the Babel JS source. The source itself is redistributed as a babel-source RubyGem with the corresponding version. This means users can easily upgrade to the latest Babel anytime its released while maintaining Ruby API compatibility.
Babel JS releases tend be released more frequently than changes to the Ruby bridge itself. So theres some automation behind releasing the source gems.
BUILD_SOURCE_GEM=1 is a special entry in the Travis build matrix that automatically builds and tests unpublished source gems.
A list of local source versions is maintained under the source-versions/ directory. This listing is diff'd against the published release list on rubygems.org to get the subset of unpublished gems that should be tested.
To test a new release, touch source-versions/1.2.3, commit the file and push the changes.
On the Travis build matrix, see the BUILD_SOURCE_GEM=1 job.
This job runs the build-gem script which fetches the babel/babel for the version and builds a local .gem file. The test-gem then runs the test suite against the gem. This catches any changes in the babel build process or API changes that may need to be made to the Ruby bridge before releasing.
While any fork can test changes against the source gem building code path, master has a special deployment designation.
Any unreleased source gem pushed to master will be automatically published to RubyGems via a Travis after_success deploy script. Unfortunately, none of the official Travis deployment providers could be used. But that may change in the future.
So core contributors may release a new source version by touching source-versions/1.2.3 and committing to master. No need to worry about special RubyGem permissions.
To complete the automation workflow, "release requests" are automatically published anytime a new tag is pushed to babel/babel. Contributors just should verify the build is green and should merge any new release.
A babel/babel Webhook is setup to POST to a Heroku instance running the pr-release script. Its only responsible for opening a PR with a new source-versions/1.x.x file. To avoid merge conflicts, the local versions are tracked as individual files rather than a single file with a list of versions.
Should the Webhook fail or a PR need to be reopened for an older version, this can all be done manually with any GitHub user or fork. Theres nothing special about the bot account or its permissions.