Buildpack detection failure during git push deployment — Scalingo build system

Answer

Scalingo rejects a deployment when the build system cannot identify a supported language or runtime from the repository root. There is no documented default fallback buildpack; if detection is ambiguous or fails, the deployment is rejected, and the user must either provide a recognizable manifest file or explicitly define a buildpack.

Likely Explanation

The build system relies on the presence of specific manifest files at the root of the repository to trigger the correct buildpack. If these files are missing, incorrectly named (case-sensitivity matters), or located in a subdirectory, the detector cannot infer the language. Common triggers include package.json for Node.js, requirements.txt or Pipfile for Python, Gemfile for Ruby, and pom.xml for Java.

Confirmed Facts

• Root Requirement: Manifest files must reside at the repository root for automatic detection to function.
• Outcome: Failure to detect a language results in a rejected deployment rather than a fallback to a generic environment.
• Manual Overrides: Users can bypass detection by setting a buildpack explicitly via the dashboard, CLI, or the BUILDPACK_URL environment variable.
• Diagnostics: The specific reason for a detection failure is logged in the build logs, accessible via scalingo build-logs <app>.

Steps to Resolve Detection Failure

1. Verify that the required manifest file for your language is present in the root directory of the branch being pushed.
2. Ensure the filename is exactly correct (e.g., package.json, not Package.json).
3. If the app uses a non-standard structure, explicitly set the buildpack using the CLI:

   scalingo env-set BUILDPACK_URL=https://github.com/scalingo/buildpack-name

4. Push the changes again:

   git push scalingo master

5. Verify the applied buildpack by checking the build logs:

   scalingo build-logs <app> | grep -i 'buildpack'

Maintaining Consistency Across Multiple Apps

To ensure repeatable development environments across multiple apps (e.g., feature-branch apps), use the following strategies:

• Manifest-Driven Parity: Use the same root-level manifest files across all branches to ensure the same buildpack is automatically selected.
• The .buildpacks File: Include a .buildpacks file in your repository. This file lists the required buildpacks in order, ensuring every app created from that repo uses the identical build stack.
• Configuration Sync: If using explicit environment variables for buildpacks, use a script to apply the same BUILDPACK_URL to all newly created apps via the Scalingo API or CLI.

To provide a more specific recommendation, please provide the output of scalingo build-logs <app> for the failed deployment.