For buildpacks, there are two phases:
Followed by a deployment (by us) (also called “the launch phase”).
The following details the configuration for said buildpacks. Whenever we show it, we assume it’s in a file called project.toml which must be in the root of your repository. We’ll use nodejs (JavaScript) as an example, but the phases apply to all languages though configuration will differ.
Unless the variable in question is a secret, it’s a good idea to commit configuration to version control. On top of that, the project.toml also allows for granular settings for build and launch phases.
Detection works based on files in your repository. For example, a Gemfile leads us to Ruby, while a composer.json leads to PHP. If your repository contains a package.json, it’s (probably) NodeJS. Repositories may contain multiple of these — for example, to build a backend and a frontend part of the application.
If for some reason, (e.g.) your JavaScript app is not in the root of the repo, you can tell our builder where it is:
[ build ]
[[ build.env ]]
name="BP_NODE_PROJECT_PATH"
value="frontend-app"
npm run build (when available) and try to guess where the artifacts land. To learn more about this, follow this link.Building describes the process before the application is packaged into the OCI image. So for example, npm install, usually followed by npm run build.
[ build ]
[[ build.env ]]
name="BP_NODE_RUN_SCRIPTS"
value="build"
[[ build.env ]]
name="BP_KEEP_FILES"
value="build/*:dist/*"
The structure of the project.toml looks a bit obscure and overly verbose (it’s a TOML file), but what we are doing is not that complex: we set environment variables for the build process. As shown in the example, [[ build.env ]] can be repeated multiple times.
This is the least complicated part - the result of the build phase is tagged and pushed to a registry and deployed to Runway. There’s nothing you need to do here.