Titanium SDK ↔ Appcelerator Cloud Build: Why does local SDK path resolution fail in production?

Question

Titanium SDK ↔ Appcelerator Cloud Build: Why does local SDK path resolution fail in production?
When building a Titanium application locally with the CLI, the tiapp.xml can reference a sdkPath that points to a custom SDK installation. The same project, when submitted to Appcelerator Cloud Build, ignores this attribute and attempts to resolve the SDK from its own build nodes. This mismatch leads to “SDK not found” or “API key validation” failures that do not appear during local builds.
The goal is to determine whether the cloud build service should honor the sdkPath defined in tiapp.xml or enforce a strict SDK version policy. The uncertainty lies in the documented behavior: the SDK documentation states that sdkPath is optional and only used by the local CLI, yet several community posts report that the cloud build silently overrides it.
Key constraints:

Local builds use Titanium SDK 8.3.0 with a custom API key placeholder.
Production builds run on Appcelerator Cloud Build nodes that enforce strict API key validation.
Code signing credentials are absent locally but present in the cloud environment.

Unresolved questions:

Does Appcelerator Cloud Build intentionally ignore sdkPath in tiapp.xml, or is this a configuration oversight?
What is the documented fallback mechanism for SDK resolution when sdkPath is missing during cloud builds?
Should the SDK provide a CLI flag to force cloud builds to use a specified SDK version, or rely on environment variables?

Zoha · Answer

The cloud build service runs on standardized Appcelerator nodes that have a pre‑installed SDK version. The sdkPath attribute in tiapp.xml is only consulted by the local Titanium CLI; Cloud Build does not read the local file system of the project, so any path reference is ignored.

Likely explanation: Cloud Build enforces a fixed SDK version defined in the project settings and validates the API key against a registered license. Because the build node’s SDK directory is immutable, it cannot resolve a custom sdkPath that points to a directory on your workstation.

Confirmed facts:

The SDK version used for Cloud Build is shown in the Appcelerator Dashboard under Project Settings → SDK Version.
Build logs will contain messages such as “SDK version mismatch” or “License validation failed” when the local SDK differs from the node’s version.
The sdkPath attribute is documented as optional and intended for local development only.

Steps to verify the issue:

Open the project in the Appcelerator Dashboard and note the SDK version selected for Cloud Build.
Run tiinfo locally to display the SDK version and the sdkPath value from tiapp.xml.
Compare the two versions; if they differ, the mismatch explains the failure.
Check the build log for any “SDK not found” or “API key validation” messages.

If the SDK version in the dashboard matches the local version, the problem may be related to API key registration rather than the path. Please provide the SDK version configured for Cloud Build, as this detail determines whether the recommendation is to adjust the project SDK setting or to use a different build environment.

Titanium SDK ↔ Appcelerator Cloud Build: Why does local SDK path resolution fail in production?

Titanium SDK ↔ Appcelerator Cloud Build: Why does local SDK path resolution fail in production?

1 answer

Your perspective belongs here.

0 question comments