Rename a few metadata update helper classes #497
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
A few classes (
Fastlane::Helper::MetadataBlock
& co.) with the same names are defined in two source files:metadata_update_helper.rb
andan_metadata_update_helper.rb
. That means when you use those classes, there really isn't any guarantee which implementation you'll get at runtime.Based on this
require an_metadata_update_helper.rb
statement, I think we would want to use the classes defined inan_metadata_update_helper.rb
in thean_update_metadata_source
fastlane action. But when running in Ruby 3, the classes (for exampleFastlane::Helper::UnknownMetadataBlock
) used in that action aren't the ones defined in thean_metadata_update_helper.rb
file.You can reproduce this issue by inspect the class's source code location. First, make the following code changes locally.
Check out the trunk branch and run
bundle exec fastlane run an_update_metadata_source
. You should see a similar output like this:Checkout branch
use-ruby-3.2.2
and run the same command. You should see output like this:The result is, the code uses the same class, but different implementations get picked up at runtime.
Solution
There are probably some historical issues underneath that I'm not aware of. And based on some pending unit tests, there probably was a plan to address those issues.
This PR doesn't intend to address all the issues hidden behind the duplicated symbols though. This PR simply wants to fix the duplicated symbols, by adding an
An
prefix to the classes defined in thean_metadata_update_helper.rb
file.I have made a major assumption here. That is the
an_update_metadata_source
fastlane action is the only one that uses the classes inan_metadata_update_helper.rb
, which is why I only changed that one source file. It would be good to get a confirmation whether this assumption is correct.Failing unit tests
One unit test doesn't agree with my changes. There are two unexpected failures in
ios_update_metadata_source_spec.rb
andgp_update_metadata_source_spec.rb
(the failing test case is in theshared_examples_for_update_metadata_source_action.rb
file.)I don't think they fail because the changes are incorrect. My assumption is those unit tests were written incorrectly. You can do a similar test as above. First, making the following code changes:
Checkout the trunk branch and run
bundle exec rspec ./spec/ios_update_metadata_source_spec.rb
. You should see output like this:That is obviously incorrect. The test case runs tests against
IosUpdateMetadataSourceAction
, but with a class defined in an_ metadata_update_helper.rb.What I did was moving that failing test case to the
Fastlane::Actions::AnUpdateMetadataSourceAction
test case, because maybe the expectations in it don't apply to theios_
andgp_
ones. Again, I'm not familiar with po file generation logic. It'd be good to get a confirmation that this change is okay.Test Instructions
I'm not entirely sure how to test this, as I don't know much about what is a "po" file and how it should be generated. I'm happy to carry out some testing if you have any suggestions.
Question
Should this change be a breaking change? The class name changes are a breaking changes, but I'm not sure if they are used outside of this library. The apps should use the actions, not the helper classes, correct?
Checklist before requesting a review
bundle exec rubocop
to test for code style violations and recommendationsspecs/*_spec.rb
) if applicablebundle exec rspec
to run the whole test suite and ensure all your tests passCHANGELOG.md
file to describe your changes under the appropriate existing###
subsection of the existing## Trunk
section.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.