[TIMOB-13396] CLI: Improve adhoc system
| GitHub Issue | n/a |
|---|---|
| Type | Epic |
| Priority | Low |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | CLI |
| Labels | cb-tooling, engSchedule |
| Reporter | Martin Guillon |
| Assignee | Chris Barber |
| Created | 2012-12-13T14:08:08.000+0000 |
| Updated | 2020-07-01T14:41:53.000+0000 |
Description
Trying to improve my publishing system i realised a few quirks in CLI for ad-hoc release:
- ad-hoc uses deploytype production. it should use "test". Why because it s the only way to difference a real production build (store) from adhoc build.For example in my tiapp.xml i mention that hockeystick(hockeyapp)and testflight modules are only present in test release. This is great cause it means i have those modules for adhoc builds, and i am still sure they wont be in my production builds!
- for deploytype "test", js are compiled on ios and not on android.
With those too fixes i have a great publishing system:
-development: no compiled js, logs, no testflight/hockeystick
-test: compiled js (so same behavior as production!), logs, testflight/hockeystick
-production: compiled js, no logs, no testflight/hockeystick
I fixed that in my branch. if you agree with me i ll will create a pull request
@Martin, so, ignoring Android, what exactly are you proposing for iOS? We currently do not allow you to change the deploy type for adhoc builds because we don't know if you're doing adhoc for testing or for enterprise distribution.
I don't see a big deal with allowing
\-\-deploy\-typeto be overridden fordist-adhoc(iOS) anddist-appstore(Android) builds.\-\-deploy\-typewould still default toproductionfor bothdist-adhocanddist-appstore.we are also suffering with this for years... our tooling is required to change variables in code before building so we know the type of build on runtime and defer if the app should connect to development environments for internal testing or production. allowing to change the deployType for adhoc builds would improve QA/QE flows greatly for teams with automated testing.
[~ygbr] Yeah, this is largely a legacy thing. Ad-hoc builds have always had a deploy type of "production". When I rewrote the Python scripts in Node.js, I kept the logic. According to Apple, ad-hoc builds are for distributing an app without the app store. Appc considered this a production release. A lot of things are coupled to the deploy type such as analytics and we wanted to ensure all distributed apps had analytics (unless opted out in tiapp.xml). Times have changed and now we have things like TestFlight and enterprise app management. It's good to revisit this topic. I will bring this issue up at the next internal architecture meeting. I think we need to determine if we can/should allow "test" in addition to "production" and if we should default to "test" or "production".
Here's the plan: We will be updating the code to allow a "test" deploy type for "dist-adhoc" builds, but still default to "production". Second, we will only allow "dist-adhoc" to select "ad hoc" provisioning profiles. You will no longer be able to select enterprise/in-house profiles. We are adding a new "dist-inhouse" target for doing In-house distributions (TIMOB-27908).