If the argument profileName exists, a request to the API will consult if there is a profile with that name.
In case the profile exists, the flag --auto-regenerate is set and the number of devices changed, the profile will be deleted and created again with all the device ids.
In case the profile exists but the flag --auto-regenerate isn't set, then the profile will be saved to the outputPath and the process will exit successfully.
Since this new flag needs the profileName, a new error profileNameMissing will be triggered when the profile name doesn't exist.
The logic in the class iTunesConnectServiceImp that determines if the profile should register devices has been moved to the enum ProfileType so it can be reused in CreateProvisioningProfileCommand
This pr adds the feature proposed here https://github.com/Tinder/sign-here/issues/21
What changes:
--auto-regenerateis set and the number of devices changed, the profile will be deleted and created again with all the device ids.--auto-regenerateisn't set, then the profile will be saved to theoutputPathand the process will exit successfully.profileNameMissingwill be triggered when the profile name doesn't exist.iTunesConnectServiceImpthat determines if the profile should register devices has been moved to the enumProfileTypeso it can be reused inCreateProvisioningProfileCommand