-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for scheme environment variables #326
Add support for scheme environment variables #326
Conversation
d39abc2
to
208246b
Compare
# LaunchAction or TestAction scheme group. | ||
# | ||
class EnvironmentVariables < XMLElementWrapper | ||
# @param [REXML::Element,Array{EnvironmentVariable},Array{Hash{String => String}}] node_or_target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the YARD documentation syntax expect Array<EnvironmentVariable>
, see http://yardoc.org/types.html for a quick cheat sheet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, you're right. First time for YARD, read through the documentation. Will fix this up all over.
Thanks for the PR, looks very promising! Ok for me once my remarks have all been addressed. |
|
||
# @return [Hash{:key => String, :value => String, :enabled => Boolean}] | ||
# The environment variable XML node with attributes converted to Hash keys | ||
def to_h |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ruby standard name for this method is to_hash
, not to_h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be differing information. From what I've read, appears that to_hash
is specifically if the object acts like a hash and can be converted with no loss of fidelity. I don't think that is the case here. I don't feel strongly though, so LMK if I'm just misunderstood.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, actually you're right, didn't know about that. Let's keep to_h
then.
e50020e
to
b102e28
Compare
# @return [Array<EnvironmentVariable>] | ||
# The new set of environment variables after addition | ||
# | ||
def assign_variable(variable) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely prefer that assign_variable
.
BTW, talking about []
and []=
it actually seem like a good addition (but still while keeping this assign_variable
of course).
While assign_variable
would take an EnvironmentVariable, Hash{Symbol=>String,Bool}
, []=
would take the variable name as key and expect the variable content as value (and would assume enabled=YES
, no way to specify enabled
with that syntax). And []
would take the variable name as key and return the EnvironmentVariable
.
That could provide a nice syntactic sugar alternative. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me. Should []
operate on enabled variables only as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, since it would return an EnvironmentVariable
anyway, I'd say let it access all variables (enabled or disabled). The user could still check the variable state once retrieved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
Sorry not to have spotted that before, but could you fix the alignment/identation of all your YARD docs? Convention is to align the text associated with
After that, I think I'm good 👍 |
1a11ee9
to
9ce8dc2
Compare
All feedback addressed and squashed the commits. |
# Assigns a value for a specified key | ||
# | ||
# @param [String] key | ||
# The key to update in the environment variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still misaligned ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
9ce8dc2
to
14e13f6
Compare
LGTM now 👍 Will merge in a few once Travis is OK. Nice work @justinseanmartin 🎉 |
Thanks for the prompt review feedback and dealing with a first time project contributor 😃 |
Then even more awesome work for a first-time contributor then! 👍 |
…-variable-support Add support for scheme environment variables
I don't think this is pushed out to the latest release yet. This would be a great enhancement to have. Is there an ETA for the next release? |
@tirodkar there's no fixed release schedule, but this will ship with 1.0 |
This resolves issue #325.
Aside from the stuff directly related to environment variables, I did some rubocop cleanup. After rebasing, the changes are mostly moot due to other changes to the .rubocop_cocoapods.yml. I also reran
rubocop --auto-gen-config
, which looks like it hasn't been run in a while. I can break these changes out to a separate PR, or remove them entirely if you'd prefer. LMK.🌈 (after the fact)