fix: add trailing slash to .toys releases.yml directory to prevent gem release mismatch

[ericmustin]

Summary

This PR addresses #1792 , which was auto-opened after a "failed" release for #1791 .

Background

Basically, our releases are controlled by the toys gem, which attempts to auto-determine which gems are candidates for release by looking at the git diff, and determining which files changed, and then associating files changed in directories to the gems associated with those directories. If a gem's directory contains a changed file, it creates a new release.

however, it's approach uses a naive .start_with? substring match to associate directories and file names.
https://github.com/dazuma/toys/blob/17ed449da8299f272b834470ff6b279a59e8070b/.toys/release/.lib/release_utils.rb#L436

In this case, we've made a change to files in exporter/otlp-metrics files (for the gem opentelemetry-exporter-otlp-metrics) but for the plain opentelemetry-exporter-otlp gem, which has a directory of exporter/otlp, it incorrectly flags changes to the former -metrics gem files with the directory exporter/otlp. This is why the #1792 CI logs show a failed release attempt for opentelemetry-exporter-otlp , and the resulting 422 response(this is re-releasing an existing release, which is invalid and causes the 422 from GH).

irb(main):001:0> "exporter/otlp-metrics/foobar.rb".start_with?("exporter/otlp")
=> true

Solution

I've added a trailing slash to the .releases.yml directory field for the opentelemetry-exporter-otlp gem definition in our .toys releases.yml file. This should resolve the mismatch, but it does technically mean we're misnaming the directory, since on disk it would be exporter/otlp. So there may be some cases where this will cause double slashes, if i understand correctly, but File.join auto-magically removes those so i think this hack may work? If not then we'll have to file an issue in toys and see if we can get it fixed upstream, or vendor/monkeypatch, or something to that effect, or we'll have to rename directories which is probably not ideal.

[kaylareopelle]

Thanks, @ericmustin!