forgejo-runner: convert to a role, de-Uptime-Kuma the health check
409-line playbook becomes a 16-line playbook plus a 318-line role with phases
split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and
four templates. forgejo_runner_vars.yml is deleted; its content is the role's
defaults.
Applies the Plan 6 Stage 0 decision: keep whatever determines whether the
service is healthy, drop the Uptime Kuma specifics, make the reporting point
pluggable. Gone from the role: the embedded Python that created monitors over
the Kuma API, the /tmp credentials file, token extraction, the systemd
Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is
the check itself, its log, the systemd unit and timer, and an honest exit code -
`systemctl is-failed forgejo-runner-healthcheck.service` now answers the
question with no monitoring system involved at all.
Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint
that accepts an HTTP ping plugs in there. A pull-based monitor wants it left
empty and reads unit state instead.
PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers
curling an endpoint that no longer answers" and Plan 6 said the check had
"nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are
pushing successfully right now (HTTP 200). Only the Ansible code and the vault
credentials were decommissioned; the service never stopped. So the existing push
URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved,
keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act
rather than a side effect. PLAN_3 and PLAN_6 are corrected.
Verified:
- task-list diff vs the old playbook shows ONLY the five Kuma tasks removed,
everything else identical and in the same order
- first run ok=22 changed=1 (the rewritten health script); both systemd units
and forgejo-runner.service came back ok, so the templates reproduce the
previous files byte-for-byte
- second run ok=22 changed=0, fully idempotent
- still reports "Ping sent successfully (HTTP 200)" from a script containing
zero Uptime Kuma references
- the 4 skipped tasks are genuine already-configured guards, checked not assumed
Two things for the next service:
- import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks,
which is the primary verification tool here; the first attempt produced a
useless diff.
- `Assert runner is running` was guarded by uptime_kuma_enabled and so had not
run since the decommissioning. It is not monitoring, it is the deployment
checking its own work - the deprecation banner swept it up with the Kuma
plumbing, and a runner that failed to start was deploying "successfully" in
silence. Ungated now. The banner was applied to contiguous blocks, so read
every uptime_kuma_enabled guard and ask whether it is monitoring or deployment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-12 18:15:29 +02:00
|
|
|
---
|
|
|
|
|
# Binary
|
|
|
|
|
forgejo_runner_version: "6.3.1"
|
|
|
|
|
forgejo_runner_arch: "linux-amd64"
|
|
|
|
|
forgejo_runner_url: "https://code.forgejo.org/forgejo/runner/releases/download/v{{ forgejo_runner_version }}/forgejo-runner-{{ forgejo_runner_version }}-{{ forgejo_runner_arch }}"
|
|
|
|
|
forgejo_runner_bin_path: "/usr/local/bin/forgejo-runner"
|
|
|
|
|
|
|
|
|
|
# Runtime
|
|
|
|
|
forgejo_runner_user: "runner"
|
|
|
|
|
forgejo_runner_dir: "/opt/forgejo-runner"
|
|
|
|
|
forgejo_runner_config_path: "{{ forgejo_runner_dir }}/config.yml"
|
|
|
|
|
forgejo_runner_labels: "docker:docker://node:20-bookworm,ubuntu-latest:docker://node:20-bookworm,ubuntu-22.04:docker://node:20-bookworm,ubuntu-24.04:docker://node:20-bookworm"
|
|
|
|
|
|
forgejo-runner: give CI jobs a Docker daemon of their own
jar-lid-archive's CI needs `docker build` and `docker compose`, and job
containers had no Docker at all: config.yml carried the stock
`container.docker_host: "-"`, which is precisely "find a daemon for the
runner and do not let jobs near it".
A docker:dind sidecar now runs on forgejo-runner-box, published on
127.0.0.1 only, and jobs build against that instead of the host daemon.
Following Forgejo's own admin docs, which make the point that this is
THREE settings and not one:
forgejo-dind.service a privileged docker:dind on the host daemon
container.docker_host tcp://127.0.0.1:2376 - where the runner
CREATES job containers
runner.envs.DOCKER_HOST + tcp://forgejo-dind.docker.internal:2375 -
container.options how a job, from INSIDE dind, reaches it
The third is the one that is easy to miss and fails identically to
having done nothing: for a tcp:// docker_host the runner mounts nothing
into the job container, so the job still finds no daemon. The two
addresses differ because they are used from different places - the
runner is a process on the host; a job container is inside dind, where
127.0.0.1 is itself. `host-gateway` is expanded by the daemon creating
the container, which is dind, so it lands on dind's own bridge gateway.
Verified on the box, along the exact path a job takes - a container on a
user-defined network, with the same --add-host and DOCKER_HOST the
runner will set: the name resolves to 172.20.0.1, `docker version`
returns the dind server, and `docker build` succeeds. The host daemon
runs forgejo-dind and nothing else.
config.yml had to become a template to do any of this. It was previously
`generate-config` run once on first deploy and never touched again, so
the repo had no say in its contents. Every value was transcribed from
the live file and diffed against it key by key: with dind disabled, 30
of 30 identical. Two deliberate differences - runner.envs drops
A_TEST_ENV_NAME_1/2, upstream's placeholders, which were being injected
into every job here; and the upstream comment blob is gone. Because the
file is managed now it also gets a restart handler, the absence of which
has bitten this repo before.
Things deliberately chosen rather than defaulted into:
- the flag lives in the playbook, not the role defaults, so the role's
default stays the configuration this host has always run and turning
it off is one line. Disabling it also tears the units down rather than
just skipping them.
- dind is a hard Requires= of forgejo-runner, and its unit stays in
"activating" until the daemon answers. A dead dind is then one red
unit instead of a green runner failing every job it claims.
- the healthcheck and monitored_services learned about dind for the same
reason: runner up + dind down is the interesting failure and it was
previously invisible.
- /var/lib/docker is a named volume, or every image is re-pulled on each
container recreation; a weekly prune keeps that from growing forever.
- dind's network pool is pinned to 172.20.0.0/14. Docker's stock pool
reaches into 192.168.x, and act_runner creates a network per job, so a
job could eventually allocate this LAN's subnet and lose the route to
every box on it.
Note this runner is SHARED - arbret, arbret-biz, arbretdos and
arbret-ops build here too, far more often, and docker_host is per-runner
not per-repo. Their workflows are unchanged but their next run pulls
images into a cold cache. Job images still need a docker client of their
own: node:{20,22}-bookworm ship none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-27 22:32:08 +02:00
|
|
|
# --- config.yml contents ----------------------------------------------------
|
|
|
|
|
# These reproduce, exactly, the stock `generate-config` output this host has
|
|
|
|
|
# been running since first deploy. They are variables now only because the file
|
|
|
|
|
# became a template; changing one of them changes the box.
|
|
|
|
|
forgejo_runner_log_level: info
|
|
|
|
|
forgejo_runner_log_job_level: info
|
|
|
|
|
forgejo_runner_capacity: 4
|
|
|
|
|
forgejo_runner_job_timeout: "3h"
|
|
|
|
|
forgejo_runner_shutdown_timeout: "3h"
|
|
|
|
|
forgejo_runner_cache_enabled: true
|
|
|
|
|
# Empty = autodetect this host's outbound address. See the note in the template
|
|
|
|
|
# before changing it; under dind this is the value that decides whether
|
|
|
|
|
# actions/cache works.
|
|
|
|
|
forgejo_runner_cache_host: ""
|
|
|
|
|
forgejo_runner_container_network: ""
|
|
|
|
|
forgejo_runner_valid_volumes: []
|
|
|
|
|
# Extra job environment and extra `docker run` options for job containers.
|
|
|
|
|
# Both MERGE with what dind adds rather than replacing it.
|
|
|
|
|
forgejo_runner_envs: {}
|
|
|
|
|
forgejo_runner_container_options: ""
|
|
|
|
|
|
forgejo-runner: convert to a role, de-Uptime-Kuma the health check
409-line playbook becomes a 16-line playbook plus a 318-line role with phases
split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and
four templates. forgejo_runner_vars.yml is deleted; its content is the role's
defaults.
Applies the Plan 6 Stage 0 decision: keep whatever determines whether the
service is healthy, drop the Uptime Kuma specifics, make the reporting point
pluggable. Gone from the role: the embedded Python that created monitors over
the Kuma API, the /tmp credentials file, token extraction, the systemd
Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is
the check itself, its log, the systemd unit and timer, and an honest exit code -
`systemctl is-failed forgejo-runner-healthcheck.service` now answers the
question with no monitoring system involved at all.
Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint
that accepts an HTTP ping plugs in there. A pull-based monitor wants it left
empty and reads unit state instead.
PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers
curling an endpoint that no longer answers" and Plan 6 said the check had
"nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are
pushing successfully right now (HTTP 200). Only the Ansible code and the vault
credentials were decommissioned; the service never stopped. So the existing push
URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved,
keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act
rather than a side effect. PLAN_3 and PLAN_6 are corrected.
Verified:
- task-list diff vs the old playbook shows ONLY the five Kuma tasks removed,
everything else identical and in the same order
- first run ok=22 changed=1 (the rewritten health script); both systemd units
and forgejo-runner.service came back ok, so the templates reproduce the
previous files byte-for-byte
- second run ok=22 changed=0, fully idempotent
- still reports "Ping sent successfully (HTTP 200)" from a script containing
zero Uptime Kuma references
- the 4 skipped tasks are genuine already-configured guards, checked not assumed
Two things for the next service:
- import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks,
which is the primary verification tool here; the first attempt produced a
useless diff.
- `Assert runner is running` was guarded by uptime_kuma_enabled and so had not
run since the decommissioning. It is not monitoring, it is the deployment
checking its own work - the deprecation banner swept it up with the Kuma
plumbing, and a runner that failed to start was deploying "successfully" in
silence. Ungated now. The banner was applied to contiguous blocks, so read
every uptime_kuma_enabled guard and ask whether it is monitoring or deployment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-12 18:15:29 +02:00
|
|
|
# The Forgejo instance this runner registers with.
|
|
|
|
|
forgejo_instance_url: "https://forgejo.contrapeso.xyz"
|
|
|
|
|
# forgejo_runner_registration_token comes from the vault.
|
|
|
|
|
|
|
|
|
|
# --- Health check -----------------------------------------------------------
|
|
|
|
|
# The check answers "is this service healthy" and records the answer two ways:
|
|
|
|
|
# a log file, and its own exit code. The exit code is the durable artefact —
|
|
|
|
|
# systemd stores it, so `systemctl is-failed forgejo-runner-healthcheck.service`
|
|
|
|
|
# answers the question with no monitoring system involved at all.
|
|
|
|
|
healthcheck_interval_seconds: 60
|
|
|
|
|
healthcheck_script_dir: /opt/forgejo-runner-healthcheck
|
|
|
|
|
healthcheck_script_path: "{{ healthcheck_script_dir }}/forgejo_runner_healthcheck.sh"
|
|
|
|
|
healthcheck_log_file: "{{ healthcheck_script_dir }}/forgejo_runner_healthcheck.log"
|
|
|
|
|
healthcheck_service_name: forgejo-runner-healthcheck
|
|
|
|
|
|
|
|
|
|
# WHERE TO REPORT HEALTH — the one place to plug in monitoring.
|
|
|
|
|
#
|
|
|
|
|
# Empty means "check, log, exit honestly, report nowhere". Set it to any URL
|
|
|
|
|
# that accepts an HTTP ping and the check will report there. Nothing in this
|
|
|
|
|
# role is specific to a particular monitoring product: the Uptime Kuma API
|
|
|
|
|
# calls, monitor creation and token handling that used to live here are gone.
|
|
|
|
|
#
|
|
|
|
|
# A pull-based monitor (Prometheus node_exporter textfile, say) needs this left
|
|
|
|
|
# empty — it reads the systemd unit state instead.
|
|
|
|
|
healthcheck_push_url: ""
|
uptime kuma: remove every live reference, repoint the probes to Gatus
Nothing in the repo pushes to, authenticates against, or is gated by Uptime
Kuma any more.
── The sixth instance of the banner bug ────────────────────────────────────
memos had `Restart memos` guarded by `uptime_kuma_enabled`, because the
deprecation banner was placed immediately above it and swept it in. It is a
HANDLER, so every memos config change since 2026-09-11 applied to disk and
silently never restarted the service. Ungated.
That is the same failure found in forgejo-runner's self-assert, phoenixd's timer
enable, mempool's three timer enables, fulcrum's restart handler and bitcoind's
restart handler. Every guard was read and asked "monitoring or deployment?"
before being deleted, which is the only reason this was caught.
── What was removed ────────────────────────────────────────────────────────
30 uptime_kuma_enabled guards across 7 unconverted service playbooks, and
the 29 Kuma monitor-creation tasks they gated (embedded Python that drove
the Kuma API, temp credential files, cleanup)
7 dead uptime_kuma_api_url definitions
7 stale DEPRECATED banners
uptime_kuma_enabled and subdomains.uptime_kuma from group_vars/all
healthcheck_push_urls from the vault - 30 push tokens
services/ntfy/setup_ntfy_uptime_kuma_notification.yml -> archive/
The explanatory comments in the six converted roles are KEPT on purpose. They
record why a handler is ungated, and deleting the explanation invites someone
to helpfully re-add the guard.
── The probes moved rather than died ───────────────────────────────────────
Eight per-service health checks were still pushing to Kuma. They are not
superseded by infra/401: that answers "is the unit running", these answer "does
the service actually respond" - an RPC call to bitcoind, a TCP connect to
Fulcrum's Electrum port, an HTTP fetch from Mempool's backend. A process can be
perfectly `active` and useless.
So they were repointed, not deleted. Gatus external endpoints take a POST with
a bearer token and success=true|false where Kuma took a GET with ?status=up, so
report() now maps up/down to true/false internally and no call site changed.
Registered by infra/403 as the `probe` group, one token per host.
Two bugs fixed while in there:
* forgejo-runner's check only ever reported SUCCESS - it exited before pushing
when the runner was down, so a failure was invisible until the heartbeat
window expired. Reporting the failure is the entire point of a check.
* All six healthcheck .service units were mode 0644 and now carry a bearer
token. They are 0600.
Verified: 91 endpoints, 91 UP, 0 DOWN. Every probe triggered by hand and
confirmed arriving. Zero Kuma URLs left in the vault, zero live references in
any playbook or role.
Still standing, deliberately: the Kuma container on watchtower, its Caddy vhost,
and the uptime.contrapeso.xyz DNS record. Turning the service off is a separate
decision from removing the code that talked to it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-14 10:30:28 +02:00
|
|
|
# Bearer token for the Gatus external endpoint. Required whenever a push URL
|
|
|
|
|
# is set: Gatus rejects an unauthenticated push with 401.
|
|
|
|
|
healthcheck_push_token: ""
|
forgejo-runner: give CI jobs a Docker daemon of their own
jar-lid-archive's CI needs `docker build` and `docker compose`, and job
containers had no Docker at all: config.yml carried the stock
`container.docker_host: "-"`, which is precisely "find a daemon for the
runner and do not let jobs near it".
A docker:dind sidecar now runs on forgejo-runner-box, published on
127.0.0.1 only, and jobs build against that instead of the host daemon.
Following Forgejo's own admin docs, which make the point that this is
THREE settings and not one:
forgejo-dind.service a privileged docker:dind on the host daemon
container.docker_host tcp://127.0.0.1:2376 - where the runner
CREATES job containers
runner.envs.DOCKER_HOST + tcp://forgejo-dind.docker.internal:2375 -
container.options how a job, from INSIDE dind, reaches it
The third is the one that is easy to miss and fails identically to
having done nothing: for a tcp:// docker_host the runner mounts nothing
into the job container, so the job still finds no daemon. The two
addresses differ because they are used from different places - the
runner is a process on the host; a job container is inside dind, where
127.0.0.1 is itself. `host-gateway` is expanded by the daemon creating
the container, which is dind, so it lands on dind's own bridge gateway.
Verified on the box, along the exact path a job takes - a container on a
user-defined network, with the same --add-host and DOCKER_HOST the
runner will set: the name resolves to 172.20.0.1, `docker version`
returns the dind server, and `docker build` succeeds. The host daemon
runs forgejo-dind and nothing else.
config.yml had to become a template to do any of this. It was previously
`generate-config` run once on first deploy and never touched again, so
the repo had no say in its contents. Every value was transcribed from
the live file and diffed against it key by key: with dind disabled, 30
of 30 identical. Two deliberate differences - runner.envs drops
A_TEST_ENV_NAME_1/2, upstream's placeholders, which were being injected
into every job here; and the upstream comment blob is gone. Because the
file is managed now it also gets a restart handler, the absence of which
has bitten this repo before.
Things deliberately chosen rather than defaulted into:
- the flag lives in the playbook, not the role defaults, so the role's
default stays the configuration this host has always run and turning
it off is one line. Disabling it also tears the units down rather than
just skipping them.
- dind is a hard Requires= of forgejo-runner, and its unit stays in
"activating" until the daemon answers. A dead dind is then one red
unit instead of a green runner failing every job it claims.
- the healthcheck and monitored_services learned about dind for the same
reason: runner up + dind down is the interesting failure and it was
previously invisible.
- /var/lib/docker is a named volume, or every image is re-pulled on each
container recreation; a weekly prune keeps that from growing forever.
- dind's network pool is pinned to 172.20.0.0/14. Docker's stock pool
reaches into 192.168.x, and act_runner creates a network per job, so a
job could eventually allocate this LAN's subnet and lose the route to
every box on it.
Note this runner is SHARED - arbret, arbret-biz, arbretdos and
arbret-ops build here too, far more often, and docker_host is per-runner
not per-repo. Their workflows are unchanged but their next run pulls
images into a cold cache. Job images still need a docker client of their
own: node:{20,22}-bookworm ship none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-27 22:32:08 +02:00
|
|
|
|
|
|
|
|
# --- Docker-in-Docker for job containers ------------------------------------
|
|
|
|
|
# Off by default. The role default is the SAFE state: `container.docker_host`
|
|
|
|
|
# stays "-", which is what this host has always run, and jobs get no Docker at
|
|
|
|
|
# all. services/forgejo-runner/deploy_forgejo_runner_playbook.yml turns it on.
|
|
|
|
|
#
|
|
|
|
|
# The shape is the one in Forgejo's own admin docs, "Utilizing Docker within
|
|
|
|
|
# Actions" -> Docker-in-Docker, and it is three moving parts, not one:
|
|
|
|
|
#
|
|
|
|
|
# 1. a docker:dind container on the HOST daemon, published on loopback only;
|
|
|
|
|
# 2. container.docker_host, which points the RUNNER PROCESS at that daemon,
|
|
|
|
|
# so job/service/step containers are created INSIDE dind;
|
|
|
|
|
# 3. runner.envs.DOCKER_HOST plus a container.options --add-host, which is
|
|
|
|
|
# what lets the JOB reach the same daemon from inside.
|
|
|
|
|
#
|
|
|
|
|
# Step 3 is not optional and not a duplicate of step 2. The two addresses are
|
|
|
|
|
# different because they are used from different places: the runner talks to
|
|
|
|
|
# 127.0.0.1 on the host, and a job container inside dind cannot - its own
|
|
|
|
|
# 127.0.0.1 is itself. Setting only docker_host gets you job containers that
|
|
|
|
|
# run in dind but still cannot find a daemon, which looks exactly like the bug
|
|
|
|
|
# we are fixing. See the README.
|
|
|
|
|
forgejo_runner_dind_enabled: false
|
|
|
|
|
|
|
|
|
|
forgejo_runner_dind_container: forgejo-dind
|
|
|
|
|
# Already present on forgejo-runner-box, and the tag the project's own workflow
|
|
|
|
|
# refers to. A floating 28.x picks up patch releases on container recreation.
|
|
|
|
|
forgejo_runner_dind_image: "docker:28-dind"
|
|
|
|
|
forgejo_runner_dind_service: forgejo-dind
|
|
|
|
|
|
|
|
|
|
# Loopback ONLY. This daemon has no TLS and no authentication, so anything that
|
|
|
|
|
# can open the port is root inside a privileged container. 127.0.0.1 keeps that
|
|
|
|
|
# to processes on this box; do not move it to 0.0.0.0 or the LAN address.
|
|
|
|
|
#
|
|
|
|
|
# The number is 2376 because the upstream docs use it. 2376 is conventionally
|
|
|
|
|
# the TLS port and this is PLAINTEXT - the port number promises nothing.
|
|
|
|
|
forgejo_runner_dind_bind_address: "127.0.0.1"
|
|
|
|
|
forgejo_runner_dind_host_port: 2376
|
|
|
|
|
forgejo_runner_dind_container_port: 2375
|
|
|
|
|
|
|
|
|
|
# The name a JOB container uses to reach the dind daemon. Resolved by an
|
|
|
|
|
# --add-host ... :host-gateway on the job container, which Docker expands in
|
|
|
|
|
# the context of the daemon that CREATES the container - dind - so it lands on
|
|
|
|
|
# dind's own inner bridge gateway, where its dockerd is listening. That is why
|
|
|
|
|
# a name is used here and not an address: the address is only knowable from
|
|
|
|
|
# inside dind, at container-creation time.
|
|
|
|
|
forgejo_runner_dind_internal_host: "forgejo-dind.docker.internal"
|
|
|
|
|
|
|
|
|
|
# Networks for the containers dind creates. act_runner makes a fresh network
|
|
|
|
|
# per job, so these multiply, and Docker's stock pool reaches into 192.168.x -
|
|
|
|
|
# the same space as this LAN. A job container that allocated 192.168.1.0/24
|
|
|
|
|
# would lose the route to every box on it, including this one. Pinning the pool
|
|
|
|
|
# well clear of the LAN removes that entirely.
|
|
|
|
|
forgejo_runner_dind_address_pool: "172.20.0.0/14"
|
|
|
|
|
forgejo_runner_dind_address_pool_size: 24
|
|
|
|
|
|
|
|
|
|
# How long the dind unit waits for its daemon to answer before failing. Cold
|
|
|
|
|
# start pulls the image and initialises /var/lib/docker.
|
|
|
|
|
forgejo_runner_dind_ready_timeout: 180
|
|
|
|
|
|
|
|
|
|
# dind keeps its own /var/lib/docker. Without a volume it is wiped every time
|
|
|
|
|
# the container is recreated, and every image every workflow uses - the
|
|
|
|
|
# playwright image alone is 3.3GB - is pulled again from scratch.
|
|
|
|
|
forgejo_runner_dind_volume: forgejo-dind-lib
|
|
|
|
|
|
|
|
|
|
# ...which then grows without bound, so it is pruned. `until=168h` keeps
|
|
|
|
|
# anything used in the last week, which is the cache that makes the volume
|
|
|
|
|
# worth having, and drops the rest.
|
|
|
|
|
#
|
|
|
|
|
# Volumes are deliberately NOT pruned: `until` does not apply to them, so
|
|
|
|
|
# --volumes here would be "delete every volume not currently attached", and a
|
|
|
|
|
# workflow's named volume between two jobs is not an obvious thing to destroy
|
|
|
|
|
# on a timer. Watch disk and prune those by hand.
|
|
|
|
|
forgejo_runner_dind_prune_enabled: true
|
|
|
|
|
forgejo_runner_dind_prune_on_calendar: "Sun 04:30"
|
|
|
|
|
forgejo_runner_dind_prune_filter: "until=168h"
|