docs: override entrypoint

docs/maintainers/handbook.md

@@ -39,7 +39,7 @@ After docker creates the filesystem and copies files into a new container it run
 
 For a simple example check the [entrypoint.sh for `croc`](https://git.coopcloud.tech/coop-cloud/croc/src/commit/2f06e8aac52a3850d527434a26de0a242bea0c79/entrypoint.sh). In this case, `croc` needs the password to be exported as an environmental variable called `CROC_PASS`, and that is exactly what the entrypoint does before running vendor entrypoint.
 
-If you write your own entrypoint, it needs to be specified in the `config` section of compose.yml. See [this handbook entry](http://localhost:8000/maintainers/handbook/#entrypoints) for more.
+If you write your own entrypoint, it needs to be specified in the `config` section of compose.yml. See [this handbook entry](/maintainers/handbook/#how-do-i-set-a-custom-entrypoint) for more.
 
 ### `releases/` directory
 
@@ -548,3 +548,91 @@ You can use [this `docker-compose` trick](https://docs.docker.com/compose/extend
 If you have a recipe that is using a `mysql` service and you'd like to use `postgresql` instead, you can create a `compose.psql.yml`!
 
 An example of this is the [`selfoss`](https://git.coopcloud.tech/coop-cloud/selfoss) recipe. The default is `sqlite` but there is a `postgresql` compose configuration there too.
+
+## How do I set a custom entrypoint?
+
+Ripped from the [`coop-cloud/peertube`](https://git.coopcloud.tech/coop-cloud/peertube) recipe but shortened down, here are more or the steps you need to take:
+
+Define a config:
+
+```yaml
+  app:
+    ...
+    configs:
+      - source: app_entrypoint
+        target: /docker-entrypoint.sh
+        mode: 0555
+    ...
+
+configs:
+  app_entrypoint:
+    name: ${STACK_NAME}_app_entrypoint_${APP_ENTRYPOINT_VERSION}
+    file: entrypoint.sh.tmpl
+    template_driver: golang
+```
+
+Define a `entrypoint.sh.tmpl`:
+
+```
+#!/bin/bash
+
+set -e
+
+file_env() {
+   local var="$1"
+   local fileVar="${var}_FILE"
+   local def="${2:-}"
+
+   if [ "${!var:-}" ] && [ "${!fileVar:-}" ]; then
+      echo >&2 "error: both $var and $fileVar are set (but are exclusive)"
+      exit 1
+   fi
+
+   local val="$def"
+
+   if [ "${!var:-}" ]; then
+      val="${!var}"
+   elif [ "${!fileVar:-}" ]; then
+      val="$(< "${!fileVar}")"
+   fi
+
+   export "$var"="$val"
+   unset "$fileVar"
+}
+
+file_env "PEERTUBE_DB_PASSWORD"
+
+{{ if eq (env "PEERTUBE_SMTP_ENABLED") "1" }}
+file_env "PEERTUBE_SMTP_PASSWORD"
+{{ end }}
+
+{{ if eq (env "PEERTUBE_LIVE_CHAT_ENABLED") "1" }}
+apt -y update && apt install -y prosody && apt -y clean
+mkdir -p /run/prosody && chown prosody:prosody /run/prosody
+{{ end }}
+
+# Copy the client files over to a named volume
+# so that they may be served by nginx directly
+cp -ar /app/client/dist /srv/client
+
+# upstream entrypoint
+# https://github.com/Chocobozzz/PeerTube/blob/66f77f63437c6774acbd72584a9839a7636ea167/support/docker/production/entrypoint.sh
+/usr/local/bin/entrypoint.sh "$@"
+```
+
+Please note:
+
+1. The `file_env` // `_FILE` hack is to pass secrets into the container runtime without exposing them in plaintext in the configuration.
+
+1. In order to pass execution back to the original entrypoint, it's a good idea to find the original entrypoint script and run it from your own entrypoint script. If there is none, you may want to reference the `CMD` definition or if that isn't working, try to actually specify `cmd: ...` in the `compose.yml` definition (there are other recipes which do this).
+
+1. If you're feeling reckless, you can also use the Golang templating engine to do things conditionally.
+
+Then, wire up the vendored config version:
+
+```
+# abra.sh
+export APP_ENTRYPOINT_VERSION=v5
+```
+
+You should be able to deploy this overriden configuration now.