Greetings,
My employer gave me access to an Ionic AppFlow “Starter” plan that includes the add-on for building native app binaries, but I have some difficulty in trying to differentiate between “development” and “production” builds within my app runtime code.
Since my main machine is a Windows PC, I create all the Android builds locally, in which I run ionic cordova build android for development builds and ionic cordova build android --prod --release for release builds. However, I don’t have ready access to a new enough Mac to build for anything newer than iOS 12, so I rely on AppFlow Package for this. Is there any way to have the same behaviour in building apps through AppFlow’s builds?
Basically, because I can’t build and run locally to debug on Apple devices, I have certain UI elements which contain debug information that I need to see in-app to allow me to debug and fix app issues. Currently I have to edit the command assigned to the NPM build script target to either include or exclude the --prod and --release flags each time I need a different build. Is this not something that AppFlow Package should (or could) handle through the “development” or “release” build types?
If not, is there something else that I can check in my app runtime code to tell which build I’m currently running?
Edit: Looking through the documentation and browsing the menu in my AppFlow Dashboard, I get the impression that the only way to control this programatically in the build process is with at least a “Growth” level Ionic AppFlow subscription… Is this correct?
I do feel this is something that should be catered for as a core part of the “Ionic Package” system, not as an extra add-on through the automation side… What’s the point in providing the option to create “development” or “release” profiles if you can’t control whether or not the app is built for “development” or “production”?
Either way, I have implemented a workaround using Git branches that seems pretty easy to maintain.
My project now has both a dev and prod environment configuration file, along with the relevant entries in angular.json to use them with both the ng and ionic CLI tools.
I also make use of Ionic Deploy, so the default plugin configuration is set to do manual updates, while the dev environment (specifically for distributing test builds) automatically updates from the “Development” channel and the prod environment automatically updates from the “Production” channel.
Now I maintain the following Git branches:
-
master as the main branch in source control (GitLab, in my case)
-
stable as the “production” branch, pushed only to Ionic AppFlow
-
develop as the “development” branch, pushed only to Ionic AppFlow
The AppFlow-only branches each contain a single commit to update the npm build command, where:
-
stable now runs ng build --prod
- this command appears to automatically pick the production environment config anyway…
-
develop now runs ng build --configuration=dev
To create a testing build at any point to distribute, I simply rebase my develop branch on the HEAD of whatever I’m working on, force push to AppFlow and create a web build.
Similarly, to update the released production app, I rebase my stable branch to the HEAD of master (after going through the typical pre-release workflow) and force push to AppFlow before creating a web build.
It it kinda hacky and it makes me feel real dirty inside, but I guess this will just have to do until something more “official” comes along. 
2 Likes
Ok, so here’s a weird one… After reading through the AppFlow Environments documentation recently, I noticed that the CI environment sets a few variables, including CI_GIT_REF_TYPE and CI_GIT_REF.
Then from one of my existing apps, I tried pushing a tag to my ionic remote and it worked fine:
At this point I thought I might get around this issue by adding a Bash script to my repo and changing the NPM build script command to run that instead, allowing me to run conditional commands based on the value of these environment variables.
So, I duly created a new project for testing, linked it to a new app in Ionic AppFlow, ran npm version to nump the version and set a tag, then I tried to push that tag to my ionic remote, exactly as I had done with my existing project. But this resulted in the following error:
remote: Error: only pushes are allowed.
remote: error: hook declined to update refs/tags/v1.0.0
To git.ionicjs.com:nortechdev/ionic-appflow-tester.git
! [remote rejected] v1.0.0 -> v1.0.0 (hook declined)
error: failed to push some refs to 'git@git.ionicjs.com:nortechdev/ionic-appflow-tester.git'
At first I thought this might be because there were no branches in my ionic remote yet, so I moved the HEAD of master to the previous commit, pushed that to ionic (which worked fine), moved master forward again to the point I had my tag and tried again, only to get the exact same error.
–
So what am I missing here, can we actually push tags to the Git repository in Ionic AppFlow or not?
1 Like
I think we have this fixed without breaking development build and without upgrading the subscription.
The CI build injects some environment variables to every build, even if you don’t pay to have custom environments. So we just check for the existence of one of those variables, CI_APP_ID, and build for production.
We changed our package.json “build” command to:
"build": "if [ $CI_APP_ID ]; then echo \"Building production release\" && ng build --prod; else ng build; fi",
Then in the AppFlow build output you can see “Building production release” and verify it is in fact building using environment.prod.ts but in development CI_APP_AP is not present so it does a normal development build.
I agree that it’s odd, when I select “release” as the build type I expected it to build with the production flag without any changes on my part. This should definitely be reflected in documentation somewhere with an official fix, but this seems to have worked for us.
1 Like
That’s an interesting idea… It doesn’t necessarily solve the initial problem, but it could very well be helpful in working around it.
Lately I’ve been making use of Apple TestFlight and Google Beta Tracks, each of which (I believe) require a build signed with a production certificate anyway. So suffice to say, I haven’t needed to use my previous workaround for this one for a while now.