--build_configuration available for "frank setup" but missing form "frank build"

[jabberjaw-dev]

Our iOS project requires a custom, non "Debug" configuration to be used.

It is possible to set up Frank with a custom build configuration with "frank setup" via the --build_configuration flag, which is great, but the subsequent build done with "frank build" always uses a hard-coded "-configuration Debug" setting.

Would it be possible to add a --build_configuration flag to the "frank build" command?

[wokkaflokka]

Going along with this, frank setup should support some arguments. For instance, suppose I am trying to automate injecting Frank into an existing XCode project (pulled down cleanly from Github). It would be nice to not have to worry about the case of "frank setup" failing, which a "--force" flag could offer. Additionally, supporting something like a "--help" flag, even if it were to say "There are no possible variants to this command, and you should feel bad", would reduce confusion.

On the other hand, I received output from Frank saying that 'frank setup' takes no arguments. However, this issue clearly contradicts that output. I think it would be best to pick ONE functionality (either arguments, or none) and explicitly support that. Secrets secrets are no fun.

frank setup --force ✘
frank setup should have no arguments: "frank setup".

If I find time, I might consider a pull request, depending on the consensus around how to proceed.

[wokkaflokka]

On top of this:

frank setup, if it finds multiple targets, will block until user input is received. this, as well, breaks the possibility of automating setup.

I find myself wondering: should this also be an optional argument to frank setup?

[moredip]

allowing frank setup to be run by a script doesn't seem that important - you only do it once when you first setup frank. That said, I'd happily accept pull requests which add these flags.

[wokkaflokka]

:) That's the beauty of open-source, isn't it? (and the downside is time...or lack thereof)

That being said, while I see the general truth in your statement, I think there are some cases where I would disagree with you.

Consider a company that makes iPhone apps, or has more than one app, or hell, has 15 different targets. In each of those cases, the number of times "frank setup" needs to be run is more than one (granted, for the latter case, you could only setup frank once per repository, but you could easily have 15 repositories).

Consider case two. A developer wants to assist QA by automating the process of them getting a frankifying an app (or in my use case, multiple apps, and additionally, over a period of time). Again, this is a case where automation can only make things better.

Consider case 3: one of the aforementioned scenarios (lots of apps, no frank) wants to frankify all of them. This scenario screams for automation.

Here's a final use case: an app being developed doesn't have automated testing support. While the active developers aren't opposed to it, they don't have time to make it a priority. They need a proof-of-concept. Now, one could walk through tediously, but if you're seeing the same pattern I am -- it's a suboptimal use of time.

Look, I think as a best practice all mobile apps should support automated testing. And if that was the case, then yes, frank setup would only need to be run once, and every branch of every app on every github repo would support frank out of the box. But let's be real: best practices are ideals to strive for, and sometimes, the day to day grind can't accommodate every best practice.

I'll see if I can find time to look into it. Additionally, if you'd be interested, I could show you what I'm trying to do in terms of automating frank installation (here's a teaser -- it has support for cocoapods, too).

(Thinking further about automating Frank install, it would allow you to test an app using Frank + CI that does not include frank [and suppose that for some corporate or personal reason, as stupid as it may be, the app cannot have it in the main install]....definitely not an optimal use case, but it exists.)

[moredip]

frank build does have a --configuration flag. Annoying that it's not the same form as the --build_configuration flag in frank setup, but I'm assuming it provides the functionality you're asking for, so I'm going to close this issue.