Closed omarzl closed 5 months ago
Thank you for this detailed issue for this new functionality.
I think this is a good idea, but I am wondering if just adding another network call for the device list simplifies this? ENTITY_ERROR seems to be very generic in nature compared to knowing the device list has changed
That's true, there is no explicit error code/type that tell us that the profile already exists. It could be error-prone.
Here is a modified flow that would make a get request first to obtain the data of the profile if it exists.
What do you think?
Also do you consider it should have the additional flag --auto-regenerate
or it should be the default behaviour without any flags?
This looks great to me, yea id add a flag to enable opt in
Hello! I know how frustrating is to regenerate the provisioning profiles for ad-hoc distribution after registering a new device.
What we did at Rappi was to evaluate if there are new devices vs the ones registered in a profile, if so, we deleted the profile and created a new one since the API doesn't allow you to modify it.
I wrote about it here https://engineering.rappi.com/ios-infra-at-rappi-1598341069b8 (Provisioning section)
So I would like to include this functionality in your tool, if that makes sense for you. Before writing any code I preferred to open this issue to discuss it.
Right now if you try to generate a profile that already exists, the tool gives you this error:
So I was thinking to include a new flag like this:
bazel run //Sources/SignHereTool:sign-here -- create-provisioning-profile --auto-regenerate
When it is active and detects this error type, it will automatically delete the profile and retry generating it. At first, I was thinking evaluating if the device list has changed but that will add a another network call 🤔
So the flow would be like this:
What do you think? Thanks!