Resolving Bluemix application push failures – application staging errors

5 min read

Resolving Bluemix application push failures – application staging errors

In the last post, I explained how to resolve client and fabric related errors when pushing applications to Bluemix. This post will present the next category of errors: application staging errors.

Application staging error with explicit buildpack specified

The first group of errors in this category happen when you use the -b option to explicitly specify a buildpack to stage your application and the buildpack cannot be retrieved successfully. The causes could be:

  • Invalid buildpack name or URL — When you specify an invalid buildpack name or url, you may see the error below:

    Server error, status code: 400, error code: 100001,<br>
    message: The app is invalid: buildpack notexist is not valid public<br>
    url or a known buildpack name

    If you need to confirm that you are using the right buildpack name, you can use the cf buildpackscommand to list the available built-in buildpacks.

  • Non-existent buildpack address — When you provide a buildpack URL that points to a non-existent address, you may see errors like below:

    Cloning into '/tmp/buildpacks/java-buildpack'...<br>
    fatal: could not read Username for 'https://github.com':<br>
    No such device or address<br>
    Cloning into '/tmp/buildpacks/java-buildpack'...<br>
    FAILED<br>
    Server error, status code: 400, error code: 170001, message:<br>
    Staging error: cannot get instances since staging failed
  • Network error when cloning the remote buildpack — Sometimes the specified remote buildpack cannot be cloned due to network errors and there is little indication in the error message, like below. But notice that it does not go beyond the “cloning” step:

    Cloning into '/tmp/buildpacks/nope-buildpack'...<br>
    FAILED<br>
    Server error, status code: 400, error code: 170001, message:<br>
    Staging error: cannot get instances since staging failed

Application staging error with detected buildpack

The second group of errors may occur when you don’t specify the buildpack to use explicitly. Bluemix will then go through a “detect” process to try to find the right buildpack for your application by examining your application package. This detect process may fail with the error message below:

Server error, status code: 400, error code: 170003, message:<br>
An app was not successfully detected by any available buildpack

Below are the possible causes:

  • Wrong application package — During the detect process, the built-in buildpacks in Bluemix will be asked in turn to determine whether they can stage your application. The buildpacks typically looks for certain “sign” files in your application package to make that decision. For example, the Node.js buildpack looks for the package.json file in the application’s root folder. If your application does not have the right sign files at the right location, detect fails. Sometimes this may be because you are simply pushing from an incorrect folder, or you are packaging the application in the wrong way. For example, a common error is having a root folder in the zip package.

  • Required buildpack not installed — Bluemix may not have the buildpack you need built in. Again, you can check the built-in ones using the cf buildpacks command.

Application staging error during compilation

The last group of errors take place when the buildpack tries to “compile” your application to produce the droplet. The ultimate error message is shown below:

Staging failed: Buildpack compilation step failed<br>
FAILED<br>
Server error, status code: 400, error code: 170004, message:<br>
App staging failed in the buildpack compile phase

You may see additional messages outputted by the buildpack before that error. They often provide good information. Some buildpacks come with better tracing support, which you can turn on to get more verbose logs:

  • Java and Liberty buildpack: set the JBP_LOG_LEVEL environment variable to DEBUG

  • Node.js buildpack: set the npm_config_loglevel environment variable to silly (or using the .npmrcfile)

  • PHP buildpack: set the BP_DEBUG environment variable to true

In order to view these logs, use the cf logs command or the cf logs <app-name> --recent command to print recent logs. In order to see the logs in “real time”, you can open another console and issue cf logs <app-name> to trail the logs.

Below are the possible causes of the compilation error:

  • Wrong application package or files — The buildpack expects certain conventions for the application files and fails to compile them if the conventions are not followed. For example, a mal-formed pacakge.json will fail the compilation of a node.js application.

  • Unable to reach external dependencies — The buildpack sometimes need to download some dependencies from the Internet in order to compile the application. If it cannot reach those dependencies, the compilation fails. For example, the node.js buildpack usually need to work with a remote NPM repository. The Security Group settings will impact the network connectivity, so make sure it’s not blocking the required connections.

  • Staging timeout — The staging time limit is 15 minutes. If the staging process takes longer than that, it gets killed silently. In order to reduce the staging time, you can consider using cached files instead of installing them during compilation. For example, you can package required node modules in your node.js application.

  • Staging using too much memory — The memory allocated to the container for staging the application is 1G bytes. If the staging process consumes more memory than that, it gets killed silently.

  • Staging using too much disk — The disk allocated to the container for staging the application is 4G bytes. The buildpack will fail to write to the disk if it goes beyond that limit. Each buildpack may output different errors in this case.

  • Using an unmatching buildpack level — When you specify an external buildpack, you may be using an unmatched version. As a best practice, always specify the version tag so that you don’t pick up the master branch which may contain breaking changes. For example, instead of using https://github.com/cloudfoundry/java-buildpack.git, use https://github.com/cloudfoundry/java-buildpack.git#v3.0.

  • Picked up by a wrong buildpack — Sometimes your application may be picked up by another buildpack unexpectedly during the detect phase. This means the application package contains some files that are interesting to that buildpack. You can always override the detect behavior by using the -b option to explicitly specify the buildpack to use, but it would be good to fix the suspicious sign files.

  • Script permission issue in the buildpack — If you are using your own external buildpack and the compile/release scripts do not have the “execution” bit in their file permission attribute, the compilation fails with little error indication. You need to use chmod to add that execution bit and make sure that bit is reserved in the GIT repository.

Hopefully this information will help you get through the application staging phase. The next major phase is the startup of the application, which I will cover in the next post of this series.

Be the first to hear about news, product updates, and innovation from IBM Cloud