-
Notifications
You must be signed in to change notification settings - Fork 271
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
support app name(s) for upgrade command. #100
Conversation
One thing I should call out is that the behaviour is changed in the case where an invalid appId which is not an integer is specified. Prior to this change Commandant will fail validation and the whole upgrade process is aborted. After this change the result is the same as when an invalid appId which is an integer is used; the id is ignored and update either continues or issues a warning about nothing to upgrade (depending on whether other apps have been specified). |
The travis failure appears to be due to some sort of PATH setup failure which eventually causes a failure due to missing xcpretty, sorry if I've missed something and it's my fault! |
@gdawg the build issues on Travis have been addressed and your branch has been updated with |
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 love this idea and want to add more support for using app names instead of IDs. There are just a couple of minor changes I'd like you to make before this gets merged.
} | ||
|
||
let ids = appIdsByName! | ||
return ids[name] |
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.
Can you replace these two lines with return appIdsByName?[name]
? That will remove the need for the forced unwrap.
mas-cli/Commands/Upgrade.swift
Outdated
if let appId = softwareMap.appIdWithProductName($0) { | ||
return appId | ||
} | ||
if let appId = UInt64($0) { |
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.
Can you move this call to handle an app ID argument before the call into appIdWithProductName
above? That way if only one or more app IDs are given on the command line, the appIdsByName
dictionary won't get built (since it won't get used).
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.
good idea!
This commit adds a step to the upgrade command which checks each input token against the list of installed apps and converts any matched productName to a productId.
9dfaaf9
to
6b0ee04
Compare
Hey mate - I brought this up to date and implemented those changes, plz have another look when you get a chance - the travis failure this time seems to be caused by issues with the "danger" configuration. I went to their website and almost passed out from how "loud" it was so I'm not sure what's going on there ;( |
@gdawg sorry about the Danger issue. Not your fault, something I need to fix on Travis. Thanks for making those changes! |
Generated by 🚫 Danger |
I'll take care of the changelog entry. |
oh cheers thx man |
This commit adds a step to the upgrade command which checks each
input token against the list of installed apps and converts any
matched productName to a productId.