In Part II we got to create a .zip file with the artifacts to be uploaded to PhoneGap Build (PGB)

Compile and forget.

The point of automating is not create a .zip file and point and click your way through PGB for it to compile. That is why PGB offers a “read” and a “write” APIs.

Being a PGB “private app” we need to call the /apps/:id endpoint and attach the .zip containing the artifacts, which raises the question: is there an easier way than crafting the HTTP calls ourselves? And there is: use the phonegap-build-api package to handle communication, authentication (using the slightly less secure token authentication) and form manipulation and learn from their documentation.

According to phonegap-build-api’s documentation on the method, attaching the file is as simple as indicating the path to the file, but since globs are used in Gulp’s src, we need to know the path to the single file matched by the glob. For that introspection we use gulp-tap.
Of course, the build task depends on the compress task but there is also this unlock task. What would it be?

Unlock it

Apps in Android may or may not be signed with a key, but iOS apps absolutely need to. For signing purposes there are manual steps to be carried out the resulting of which is some signing keys uploaded to PGB. From then on, those keys can be used to sign the application while building. We chose to have a key per build environment, but you can do differently. In any case, those keys are unlocked (suitable for build) for a period of time, after which, they lock again, resulting in failed builds. To prevent those failed builds keys need to be unlocked and, fortunately enough, the unlocking process can be automated via the API.

Watch it! There is no such thing as updating an existing signing key. If you are referring to keys by id (like we do), changing the iOS provisioning profile requires creating a new key (that has a new id), which forces us to change the keys in our config.js. We chose to cope with it (changing config.js is part of the manual process of adding test devices to the provisioning profile and uploading it again) but one can overcome this small annoyance by getting the keys by name via the API and extracting the key before unlocking or building.
Watch it! I found little documentation about the format of the data to be sent when unlocking the key (the unlockData object from our example). If you do not follow this structure: { form: { data: { password: 'your_password' } } } (or { form: { data: { key_pw: 'kP4zzw0rd', keystore_pw: 'p4zzw0rd' } } } for Android) the call to unlock will say yay! while the build will say nay! and then your frustration levels soar with every try.