`common.TouchFile` opened files with `O_TRUNC`, so the call from `common.SshTask.Execute` against `~/.ssh/known_hosts` emptied the dokku user's previously trusted host keys before `goph.DefaultKnownHosts()` read them. Running `scheduler-k3s:cluster:add` without `--insecure-allow-unknown-hosts` then failed with `knownhosts: key is unknown` and left a zero-byte `known_hosts`. The function now matches `touch(1)` semantics: create the file if missing, otherwise leave its contents intact.
Kubernetes 1.20 deprecated the node-role.kubernetes.io/master label and replaced it with node-role.kubernetes.io/control-plane, and 1.24 dropped the legacy label entirely. The scheduler-k3s:cluster:add join path still filtered control-plane nodes with master=true, so on any k3s release built from Kubernetes 1.24+ the lookup matched zero nodes and aborted with "no nodes found in the cluster" before the worker could join.
Annotation and label values containing a newline previously round-tripped
as two adjacent `key: value` lines, and the second line then failed the
`SplitN(line, ": ", 2)` parse on read. Move the per-`(processType,
resourceType)` files to `PropertyMap*` storage so `\n` in values and `/`
in keys are preserved verbatim. An idempotent `TriggerInstall` migration
walks `--global` and every app, converting any legacy line-formatted file
in place by probing `PropertyMapGet` first and rewriting via
`PropertyListGet` only when the probe fails. Property names are
unchanged, so the annotations/labels report scanner and the
`reservedAnnotationPrefixes` filter keep working without modification.
Closes#8719.
PropertyMap tests went through SetPermissions, which looks up the `dokku` user/group; the fresh `golang:1.26.2` container used by `go-test-plugin-in-docker` has neither, so the chown failed with `unknown group dokku`. Override `DOKKU_SYSTEM_USER` and `DOKKU_SYSTEM_GROUP` to `root` in the property and chart-migration test setups so the chown targets an identity that exists everywhere. The config tests also called `plugn trigger post-config-update` without `PLUGIN_CORE_AVAILABLE_PATH` set, so the hook tried to source `/common/functions` and logged a noisy warning on every test; point the env var at the canonical `/var/lib/dokku/core-plugins/available` location.
Chart property names containing `/` failed because per-key flat-file storage interpreted the slash as a filesystem path separator, and any move to line-based storage would silently truncate multi-line values. A new `PropertyMap*` helper family in `common` persists each map as a single JSON file so both `/` in keys and `\n` in values round-trip losslessly. Chart overrides move to `chart-overrides.<chart>` and an idempotent `TriggerInstall` migration rewrites any legacy `chart.<chart>.<key>` files into the new layout. The deprecated `scheduler-k3s:set --global chart.*` form is rerouted through the same map storage so it does not silently orphan writes. Closes#8717.
The scheduler-k3s plugin exposes `annotations:set` and `labels:set` but no matching report subcommands, so scripts could not inspect the configured state for idempotent management without reading the property files directly. The new `scheduler-k3s:annotations:report` and `scheduler-k3s:labels:report` surface the configured entries with stdout, JSON, single-flag query, and `--process-type` / `--resource-type` filtering, mirroring the recently added `scheduler-k3s:charts:report`. The literal `GlobalProcessType` value `--global` is rendered as `global` in report keys to avoid leading dashes. The `scheduler-k3s:autoscaling-auth:report` command is updated alongside to loop over every app when no app and no `--global` flag is provided, matching the convention used by `scheduler-k3s:report`.
Helm chart overrides on the scheduler-k3s plugin were previously set
through the generic `scheduler-k3s:set --global chart.<chart>.<property>`
interface, which mixed chart-level configuration into the same command
that manages scheduler properties and offered no focused way to inspect
which overrides were configured. A dedicated `scheduler-k3s:charts:set`
sets and clears chart-specific helm values, and a complementary
`scheduler-k3s:charts:report` surfaces configured overrides per chart
with optional JSON output and single-field flag queries. The legacy form
on `scheduler-k3s:set` continues to work but now emits a deprecation
warning pointing users at the new subcommand.
storage:report gains a flat dotted key per attachment field (entry-name, host-path, container-path, phases, process-type, subpath, readonly, volume-options, volume-chown) under the --storage-attachment.<index>.<field> shape. Both stdout and JSON pick the keys up through the existing common.ReportSingleApp pipeline. Attachments that reference a missing storage entry emit a warning and are skipped, so the rest of the report still renders. Closes#8710.
Re-running `storage:mount <app> <entry> --container-dir <path>` against an existing `(entry, container_dir, process_type)` tuple now updates the attachment's mount-time fields in place instead of erroring with `already mounted`. Declarative tooling that wants to change `--volume-options`, `--volume-chown`, `--phase`, `--volume-subpath`, or `--volume-readonly` on an existing mount no longer has to unmount-then-remount, which briefly dropped the volume from `storage:report` and raced against any deploy that fired in the window. The legacy `host:container[:opts]` form keeps its strict `Mount path already exists.` failure.
The `storage:list <app> --format json` payload conflated the
attachment's `Readonly` flag and its `VolumeOptions` field into a
single derived `volume_options` string that rendered as `ro`,
`<options>`, or `ro,<options>` depending on which fields were set on
the underlying attachment. That shape is fine for the legacy
`host:container[:options]` text view but it leaves drift-detection
tooling unable to tell whether a `ro` token came from
`Attachment.Readonly == true` or from the operator setting
`Attachment.VolumeOptions = "ro"` directly. The JSON now exposes
`readonly` (boolean) and `volume_options` (string) as separate
omitempty keys populated straight from the attachment, and
`formatStorageListEntry` combines them at format time for the colon-
form text view. `ParseMountPath` was extended in lockstep so callers
of the legacy `host:container:opts` form no longer have to special-
case the `ro` token themselves.
The named-entry form of `storage:mount` had no way to set the attachment's `volume_options`, even though the legacy `host:container:opts` colon form parses options into the same field and every downstream consumer (the docker-args trigger and the storage:list/storage:report display path) already renders them. Tooling that declaratively re-applies attachments silently dropped options on every re-apply.
The apps plugin accepted `apps:set --global deploy-source` and
`apps:set --global deploy-source-metadata` even though nothing reads
those properties globally, accepted `apps:set <app> disable-autocreation`
even though only the global form is consulted by `maybeCreateApp`, and
never emitted `disable-autocreation` in `apps:report` for either scope.
Drop the global `deploy-source*` writes from `GlobalProperties`, reject
per-app `disable-autocreation` writes at the plugin level, and surface
`--app-global-disable-autocreation` in both the per-app and `--global`
reports so the property the runtime actually reads is round-trippable.
storage:create --chown invoked chown-storage-dir with the full host path, but the helper validates a basename and prepends the storage root itself, so every call failed with `Directory can only contain the following set of characters`. Pass the entry name and reject the combination of --chown with a non-default host path, since the helper only manages the default storage location.
# History
## 0.38.10
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.38.10/bootstrap.sh
sudo DOKKU_TAG=v0.38.10 bash bootstrap.sh
```
### New Features
- #8702: @josegonzalez Prompt for confirmation on storage:destroy
### Tests
- #8698: @dependabot[bot] chore(deps-dev): bump org.apache.maven.plugins:maven-dependency-plugin from 3.10.0 to 3.11.0 in /tests/apps/java
`storage:destroy` now prompts for confirmation before removing a named storage entry, matching the behavior of other destructive commands such as `apps:destroy` and `network:destroy`. The prompt can be skipped with the `--force` flag or the global `dokku --force` flag for non-interactive callers.
Emitting the restart policy as a `--restart` argument from a `docker-args-process-deploy` trigger exposed a latent gluing bug: proxy and builder triggers concatenated `$STDIN$output` with no separator, and the scheduler and builders appended `docker-args-process-*` output directly onto the older `docker-args-*` output, so adjacent arguments could merge into values like `--restart=on-failure:10--label`. A space is now inserted at both the trigger echo and the concatenation so arguments always stay separated.
`dokku ps:set <app> restart-policy` with no value erroneously returned `Invalid restart-policy specified` instead of unsetting the property like every other ps property. The restart policy is now managed as a normal app and global property surfaced through the `--ps-restart-policy`, `--ps-global-restart-policy`, and `--ps-computed-restart-policy` report flags, with the effective value applied at deploy time and existing values migrated on install. Because it is no longer stored as a Docker option it no longer appears in `docker-options:report`, and `--ps-restart-policy` now reports the raw value with the `on-failure:10` default available via `--ps-computed-restart-policy`.
Exposes raw, global, and computed report flags for every openresty per-app property and allows those properties to be set with `--global`, so external tooling can distinguish a property that was never set from one left at its built-in default. The computed value resolves the per-app value first, then the global value, then the default. Also corrects `client-header-timeout` which read the `client-body-timeout` key and sets the computed `client-max-body-size` default to `1m`.
