Tinder / sign-here

A straightforward tool that enables the creation of Provisioning Profiles and Certificates for deploying Apple based software
35 stars 7 forks source link

[Proposal] Auto regenerate provisioning profiles #21

Closed omarzl closed 5 months ago

omarzl commented 5 months ago

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:

Error: [iTunesConnectServiceImp] Unable to decode response
- Decoding Error: keyNotFound(CodingKeys(stringValue: "data", intValue: nil), Swift.DecodingError.Context(codingPath: [], debugDescription: "No value associated with key CodingKeys(stringValue: \"data\", intValue: nil) (\"data\").", underlyingError: nil))
- Response: {
  "errors" : [ {
    "id" : "da562397-d8ca-4df3-b55f-79eff707aa59",
    "status" : "409",
    "code" : "ENTITY_ERROR",
    "title" : "There is a problem with the request entity",
    "detail" : "Multiple profiles found with the name 'Test'.  Please remove the duplicate profiles and try again."
  } ]
}

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!

tinder-maxwellelliott commented 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

omarzl commented 5 months ago

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.

provisioning

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?

tinder-maxwellelliott commented 5 months ago

This looks great to me, yea id add a flag to enable opt in