plugins/builder-herokuish/builder-detect

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

trigger-builder-herokuish-builder-detect() {
  declare desc="builder-herokuish builder-detect plugin trigger"
  declare trigger="builder-detect"
  declare APP="$1" SOURCECODE_WORK_DIR="$2"
  local ARCHITECTURE="$(dpkg --print-architecture 2>/dev/null || true)"

  if [[ "$ARCHITECTURE" == "arm64" ]] && [[ "$(fn-builder-herokuish-computed-allowed "$APP")" != "true" ]]; then
    return
  fi

  if fn-has-buildpacks-file "$SOURCECODE_WORK_DIR"; then
    echo "herokuish"
    return
  fi

  if fn-has-buildpack-dotenv "$SOURCECODE_WORK_DIR"; then
    echo "herokuish"
    return
  fi

  if fn-has-buildpack-env "$APP"; then
    echo "herokuish"
    return
  fi
}

trigger-builder-herokuish-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/builder-herokuish/functions"`
fix: allow the herokuish builder to be detected when the computed allowed value is set not set to false 2023-01-15 12:28:06 -05:00			`source "$PLUGIN_AVAILABLE_PATH/builder-herokuish/internal-functions"`
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			`set -eo pipefail`
			`[[ $DOKKU_TRACE ]] && set -x`

			`trigger-builder-herokuish-builder-detect() {`
			`declare desc="builder-herokuish builder-detect plugin trigger"`
			`declare trigger="builder-detect"`
			`declare APP="$1" SOURCECODE_WORK_DIR="$2"`
feat: disable herokuish usage on both armhf and arm64 platforms We will not provide support for herokuish on either as herokuish is meant to be Heroku-compatible, and the Heroku stack does not support arm. Use 'pack' or Dockerfiles for app building instead. 2022-05-22 17:12:52 -04:00			`local ARCHITECTURE="$(dpkg --print-architecture 2>/dev/null \|\| true)"`
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
chore: remove ARM support Building/testing for ARM does not happen often - the only runtime environment is Raspberry PI, which supports ARM64 - and complicates support for a ton of features. Aside from that, CI runs are much longer for ARM Dokku images, often reaching 15-20 minutes or just timing out completely. Rather than support an architecture that doesn't have much usage by maintainers and has a lot of maintenance burden, we're removing the platform. 2023-08-27 12:00:34 -04:00			`if [[ "$ARCHITECTURE" == "arm64" ]] && [[ "$(fn-builder-herokuish-computed-allowed "$APP")" != "true" ]]; then`
			`return`
fix: skip herokuish version in report output and disable the herokuish builder on armhf architectures We don't skip pack as in theory they may be able to support arm in the future. Dockerfile builds should work fine, as long as all images in the FROM directives have arm versions. Finally, the null builder _should_ always work, but of course YMMV :D 2021-10-28 10:01:36 -04:00			`fi`

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			`if fn-has-buildpacks-file "$SOURCECODE_WORK_DIR"; then`
			`echo "herokuish"`
			`return`
			`fi`

			`if fn-has-buildpack-dotenv "$SOURCECODE_WORK_DIR"; then`
			`echo "herokuish"`
			`return`
			`fi`

			`if fn-has-buildpack-env "$APP"; then`
			`echo "herokuish"`
			`return`
			`fi`
			`}`

			`trigger-builder-herokuish-builder-detect "$@"`