How we pick stack and buildpacks for staging

Saving Lifecycle on the App

V3AppsController

• AppLifeCycleProvider chooses docker vs buildpacks here
• Creates an lifecycle (AppBuildpackLifecle) and passes it to AppCreate to be saved in DB.

AppBuildpackLifecycle

• Given a message with requested buildpacks, fetches and validates them
• If no stack was requested, store the default stack on the app

BuildpackLifecycleFetcher

• Finds the stack in DB
• Fetches the requested buildpacks from the DB
• Some buildpacks aren't found in the DB because they are github urls or nonexistent.
• Preserves requested buildpack order
• Allow matching buildpacks on 'nil' unknown stacks and exact stack matches.
• Maps to BuildpackInfos

BuildpackLifecycleDataValidator

• Validates the combination of buildpacks and stacks.

BuildpackInfos

• Small class
• Primary responsibility is to set buildpack_url for git buildpacks

Saving in DB

• Lifecycle data is actually saved in buildpack_lifecycle_data and buildpack_lifecycle_buildpacks tables.
• BuildpackLifecycleData has a buildpack field, but it's for legacy use.
• Normally, BuildpackLifecycleData is linked to either an app or a build & droplet. The buildpack_lifecycle_data has many BuildpackLifecycleBuildpacks.
• Additional validation on these models.

End result is that buildpacks and stack get saved on lifecycle on the app in the DB

Staging / Creating a build

V3BuildsControllers

• basic string validation is in BuildpackLifecycleDataMessage
• LifecycleProvider switches between buildpacks and docker similar to AppLifecycleProvider here
• Calls Buildcreate with lifecycle

BuildpackLifecycle

• Similar to AppBuildPackLifecycle (creates lifecycle from a message object)
• Key difference: buildpacks and stack can be requested on the message on stage request, or fall back to the what is saved on the app's lifecycle.

BuildCreate action

• Calculates staging_details from the package (along with memory, disk, environment variables, etc).
• lifecycle is nested on the staging_details.
• Calls the Stager with the staging_details

Stager

• Responsibility (once was to hold Diego staging logic vs DEA staging logic?)
• Calls the Messenger with staging_details

Messenger

• Creates a task definition using the TaskRecipeBuilder and staging_details and passes off to BbsStagerClient

TaskRecipeBuilder

• Responsibility: Defines all the fields to pass to Diego
• The stack is called root_fs
• Buildpacks are passed in the action
• These two fields are calculated using the LifecycleProtocol, which then chooses BuildpacksLifecycleProtocol

BuildpacksLifecycleProtocol

• Responsibility:
• The stack comes from staging_details
• The buildpacks are calculated using staging_details and BuildpackEntryGenerator

BuildpackEntryGenerator

• Handles user-specified buildpacks vs autodetection
• For autodetection, return all the admin buildpacks.
• For user-defined buildpacks, adds skip_detect field and return those.

StagingActionBuilder

• Translates arguments into download actions and stage action commands