`cron:set --global` wrote the property but emitted `unknown flag: --global` because the post-set `scheduler-cron-write` trigger received `--global` as the appName arg, which pflag rejected before reaching the trigger body.
The trigger args now omit appName for global writes, and the `scheduler-k3s` cron-write trigger short-circuits when called without an app since per-app reconciliation requires a real app name. The docker-local trigger already regenerates the global crontab from all apps so global `mailfrom`/`mailto` are picked up without any further changes.
The Docker daemon refuses any endpoint settings on the default bridge network and `docker compose` unconditionally attaches the service name as an alias on every joined network, so combining bridge with user-defined networks via compose's `networks:` block is impossible. When `vector-networks` is set, the compose template now joins only the configured networks; outbound to external sinks still works through user-defined network NAT. Additionally, `vector-image` and `vector-networks` are both global-only but `common.CommandPropertySet` silently accepts them at app level by merging global-only keys into the valid-property set, so both now reject explicitly in `validateSetValue`.
The dokku entrypoint already exports DOKKU_ROOT, PLUGIN_PATH, PLUGIN_AVAILABLE_PATH, PLUGIN_ENABLED_PATH, PLUGIN_CORE_AVAILABLE_PATH and DOKKU_LIB_ROOT before invoking plugn. Delegating to `dokku plugin:trigger` keeps the helper at env-var parity with the production trigger path without enumerating every var the helper must forward.
Triggers that call verify_app_name or otherwise reference $DOKKU_ROOT fail under bats because the helper did not forward DOKKU_ROOT to the plugn subshell. The production dokku entrypoint exports DOKKU_ROOT before invoking plugn, so bring the helper to env-var parity.
Adds a new global `vector-networks` property on the logs plugin that takes a comma-separated list of Docker networks. When set, the rendered compose file declares each network plus `bridge` as external and joins them on the vector service, so `docker compose up` reconciles attachments on every `logs:vector-start`. When unset, the existing `network_mode: bridge` template is preserved unchanged. The value is validated against `docker network inspect` at set time, rejects the reserved `bridge` entry, and is surfaced in `dokku logs:report` via `--logs-vector-global-networks`.
The dokku entrypoint exports both vars before invoking plugn, so triggers that source `$PLUGIN_AVAILABLE_PATH/...` work in production. The helper only forwarded PLUGIN_PATH / PLUGIN_CORE_AVAILABLE_PATH / DOKKU_LIB_ROOT, so triggers that follow the same pattern fail under bats.
The new certs-set / certs-remove tests called plugn directly via /bin/bash -c, which exits with 'PLUGIN_PATH is not set in environment' under the bats runner. Route the calls through the existing run_plugn_trigger helper so the required PLUGIN_PATH / PLUGIN_CORE_AVAILABLE_PATH / DOKKU_LIB_ROOT vars are set.
The ports plugin's `post-certs-update` trigger was rewriting every `https:443:*` mapping from the app's `http:80:*` mappings, silently overwriting any user-defined mapping such as `https:443:443` used by apps that terminate TLS inside the container. The trigger now skips the rewrite when an `https:443:*` mapping already exists, keeping the default behavior only when the app has no explicit HTTPS mapping configured.
Closes#8619.
The bare `tls-internal` key previously returned the computed value, so external tooling could not tell whether the property had been set on the app or was merely defaulting to `false`. The property is now also configurable with `--global`, the report exposes `computed-tls-internal` and `global-tls-internal` keys alongside the bare raw key, and the deploy path honors the per-app value with a fallback to the global value before the built-in default. Closes#8625.
Adds `certs-set` and `certs-remove` plugin triggers so other plugins can install or remove an app's SSL cert/key pair without shelling out to the `dokku certs:add` / `dokku certs:remove` subcommands. Shared implementations live as `fn-certs-set` and `fn-certs-remove` in `plugins/certs/internal-functions`, with the subcommands and the new triggers calling `verify_app_name` before delegating.
# History
## 0.38.4
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.38.4/bootstrap.sh
sudo DOKKU_TAG=v0.38.4 bash bootstrap.sh
```
### Bug Fixes
- #8615: @josegonzalez Reject per-app sets for openresty global-only properties
- #8613: @josegonzalez Expose raw deploy-branch and keep-git-dir in git:report
- #8549: @josegonzalez Route CNB images through launcher on scheduler-k3s
### New Features
- #8614: @josegonzalez Split scheduler-docker-local report into raw, computed, and global
### Documentation
- #8603: @cheif Add `dokku-http-oauth` to community plugins
### Tests
- #8618: @josegonzalez Isolate scheduler-k3s registry tags per bats file
- #8616: @josegonzalez Migrate from junit_files to files in EnricoMi/publish-unit-test-result-action
- #8617: @josegonzalez Upgrade actions in shared build-image compose action
- #8609: @josegonzalez Skip packer lint job on dependabot PRs
- #8604: @dependabot[bot] chore(deps): bump python from 3.14.3-bookworm to 3.15.0b1-bookworm in /tests/apps/dockerfile-release
### Dependencies
- #8606: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.50.0 to 0.51.0 in /plugins/common
- #8608: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.45 to 2.11.46 in /plugins/scheduler-k3s
- #8607: @dependabot[bot] chore(deps): bump dokku/openresty-docker-proxy from 0.10.0 to 0.11.0 in /plugins/openresty-vhosts
- #8605: @dependabot[bot] chore(deps): bump python from 3.14.3-alpine to 3.15.0b1-alpine in /docs/_build
Parallel `unit.scheduler-k3s-*` matrix jobs all pushed to the same `savant/rdmtestapp:1` tag on Docker Hub, so a herokuish run pod could pull a CNB or dockerfile image that another job had just overwritten and fail with `exec: "/exec": stat /exec: no such file or directory`. The image-repo-template now embeds the bats file basename so each job owns its own tag namespace.
