plugins/builder-pack/builder-detect

#!/usr/bin/env bash
source "$PLUGIN_AVAILABLE_PATH/config/functions"
set -eo pipefail
[[ $DOKKU_TRACE ]] && set -x

trigger-builder-pack-builder-detect() {
  declare desc="builder-pack builder-detect plugin trigger"
  declare trigger="builder-detect"
  declare APP="$1" SOURCECODE_WORK_DIR="$2"

  if [[ -f "$SOURCECODE_WORK_DIR/project.toml" ]]; then
    echo "cnb"
    return
  fi

  if [[ "$(config_get "$APP" DOKKU_CNB_EXPERIMENTAL || true)" == "1" ]]; then
    echo "cnb"
    return
  fi
}

trigger-builder-pack-builder-detect "$@"
feat: allow builders to be detected based on repository contents Rather than hardcode two builders, allow builders to specify a `builder-detect` trigger. This trigger can be used to specify if the builder should or should not be used for an application. Each builder takes stdin and can decide if it wants to emit it or emit it's own image source type. If the final value is empty, then Dokku will default to herokuish (and cnb once that is stable). In addition, a future change may allow users to manually specify a builder in the case they wish to override the choice selected by Dokku. This change enables users to build custom builder plugins and have those plugins used for building an image asset. By way of example, an enterprising user could create a `builder-lambda` based on lambci, and then pair this with a scheduler plugin that updates a lambda function on AWS. Alternatively, a user might decide they wish to place their Dockerfile in a specific directory for their applications - such as an `_infrastructure` directory - and create a plugin to override how that is detected within Dokku. 2021-02-04 01:34:12 -05:00			`#!/usr/bin/env bash`
			`source "$PLUGIN_AVAILABLE_PATH/config/functions"`
			`set -eo pipefail`
			`[[ $DOKKU_TRACE ]] && set -x`

chore: rename builder-cnb to builder-pack 2021-02-28 15:29:20 -05:00			`trigger-builder-pack-builder-detect() {`
			`declare desc="builder-pack builder-detect plugin trigger"`
feat: allow builders to be detected based on repository contents Rather than hardcode two builders, allow builders to specify a `builder-detect` trigger. This trigger can be used to specify if the builder should or should not be used for an application. Each builder takes stdin and can decide if it wants to emit it or emit it's own image source type. If the final value is empty, then Dokku will default to herokuish (and cnb once that is stable). In addition, a future change may allow users to manually specify a builder in the case they wish to override the choice selected by Dokku. This change enables users to build custom builder plugins and have those plugins used for building an image asset. By way of example, an enterprising user could create a `builder-lambda` based on lambci, and then pair this with a scheduler plugin that updates a lambda function on AWS. Alternatively, a user might decide they wish to place their Dockerfile in a specific directory for their applications - such as an `_infrastructure` directory - and create a plugin to override how that is detected within Dokku. 2021-02-04 01:34:12 -05:00			`declare trigger="builder-detect"`
			`declare APP="$1" SOURCECODE_WORK_DIR="$2"`

			`if [[ -f "$SOURCECODE_WORK_DIR/project.toml" ]]; then`
			`echo "cnb"`
			`return`
			`fi`

			`if [[ "$(config_get "$APP" DOKKU_CNB_EXPERIMENTAL \|\| true)" == "1" ]]; then`
			`echo "cnb"`
			`return`
			`fi`
			`}`

chore: rename builder-cnb to builder-pack 2021-02-28 15:29:20 -05:00			`trigger-builder-pack-builder-detect "$@"`