All, how do you manage DisableDeploy config across environments?
I want to have DisableDeploy value set to true during Appflow build, without the need to change the source code and commit.
The official documentation suggests re-generating it either via a CLI or manually. Both are error prone.
The suggestion to use different channels is an interesting workaround, but then my question would be, is there any easy way to change the target channel (in strings.xml) via an Environment?
I would much rather set up my Envrionments once, and then just select the one I want to build, native or otherwise and live-update.
You could potentially use Trapeze with an environment variable to update the xml file and then pass the environment variable using a custom Environment in Appflow.
Thanks.
Just to understand what you propose.
I love Trapeze. Despite shortcomings. e.g the inability to copy folders or many files in one command. Yet, to me Trapeze is another CLI that official recommendation I quote refers to. Trapeze is better than sed in manipulating xml files in queiton. Still a step at dev time I would like to avoid.
I wish Appflow offered running Trapeze as an optional step in the build process. Wow that would be huge. To the best of my understanding, this is not the case. So I am back to my original understanding. If I want to build/debug locally first, then deploy via Appflow, I’ll have to do an interim run of some script to modify the configuration (strings.xml in this case) and then Appflow-build.
You can run Trapeze as a step in the build process with a custom Appflow build command. See the example here which uses Trapeze and a custom build command to auto-increment the build number based on an environment variable. You could have a Trapeze config that updates the XML file based on an environment variable, which you could set at build time with a custom environment.
Keep in mind that this would always run Trapeze as it will be built into the build step, so you’ll want to account for any required environment variables for each build.
Got it. A very good pointer.
Actually I looked at the example you refer to. Trapeze (or any other scripting CLI I guess) provides a good deal of flexibility. This is very much welcome news. I thought about using my own shell script, but I agree trapeze is way better for this, and many other similar build related modifications.
What I did not like, not that I expect you do anything about it, is how the web build was distinguished from the native build, using CI_PLATFORM environment variable. It is an elegant way, perhaps, and sure works. Yet, I posit, it is unnecessariuly verbose and error prone.
Would you agree that having a build command (like “appflow:build”) as an varialbe assignable in an Appflow Enviornment sturcture solved it ?
I could have one for web and another for full native, and I could have different build commands applying different trapeze yaml configurations.
I already use Appflow Enviornments, setting Angular environment configuration, Android flavor, and more.
Also my suggestion is not without a precedent. This is how one can (and we do) override the Node versoin, for example.