[fastlane_core] symbolize keys in options of type Hash #19424
Conversation
When Hash options are provided via environment, they are parsed as JSON and auto-converted to a hash. However, Ruby treats string and symbol keys differently, and fastlane actions normally expect keys as symbols.
joshdholtz
changed the title
This reverts commit 066fb0b.
Parse JSON properly when fetched from environment variable.
Yeah! I saw that l10n tests failed in CI, probably for the opposite reason. In fact such a change might have subtle and undesired consequences. Therefore, I reverted the global change and restricted the fix to the |
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
@googlebot I consent. |
|
@googlebot I consent. |
There was a problem hiding this comment.
Congratulations! 🎉 This was released as part of fastlane 2.196.0 🚀
Checklist
bundle exec rspecfrom the root directory to see all new and existing tests passbundle exec rubocop -ato ensure the code style is validMotivation and Context
When Hash options are provided via environment, they are parsed as JSON and auto-converted to a hash. However, Ruby treats string and symbol keys differently, and fastlane actions normally expect keys as symbols.
Description
Converts keys to symbols when parsing an option from a JSON string in the environment.
Testing Steps
The
APP_STORE_CONNECT_API_KEYenvironment variable is a common example exposing the issue. Any key inside the JSON would be parsed as nil, because accessing e.g."key_id"(parsed) is different than:key_id(expected).