[Feature] Support glob wildcard patterns in <name> requests

[LeeNX]

What would you like Docksentry to do?
Please can we get support to use glob wildcard patterns in requests, like /status, /check and /update.

Why is this useful?
Been able to address requests to multiple containers in Telegram and Webhook requests to do multiple requests to similar containers.

Possible implementation (optional)
I was hoping for a list with details. Maybe a RegEx or glob wildcard for the /status pattern check. ie: /status ctf-*-even, but then I would like a similar pattern usage for /check and /update

Your setup

• Docksentry version: v.1.28.2
• Notification channels used: Telegram / Webhook
• Deployment: Docker run / Docker Compose / podman-compose

[amayer1983]

Love this — and it builds naturally on what's already there (the name resolver does partial matching today, so glob is the next step).

How I'd approach it:

• Resolver: if the <name> arg contains *, ? or [...], switch from "resolve one" to "match many" (case-insensitive fnmatch against running container names). No glob chars → today's exact/partial behaviour, unchanged.
• /status <glob> — read-only, the safe place to start: list each match (compact line per container, since *arr could be a lot).
• /check <glob> — scope the check to matches instead of all containers.
• /update <glob> / /restart <glob> — act on every match. These are the powerful ones, so I'd show which containers matched and have it go through the normal confirm/result flow rather than silently firing on a dozen at once.

One question so I build the right thing first: which of these is most useful to you day-to-day — read-only /status//check querying, or the /update//restart bulk actions? I'll start there.

(/status ctf-*-even is a great concrete example — that "even/odd" split is exactly where exact names get tedious.)

[amayer1983]

Shipped a first cut in v1.29.0 🎉 — and I ended up doing both sides you mentioned, since they fell out naturally:

• /status <glob> — your exact example: /status ctf-*-even gives a compact one-line-per-match overview (read-only).
• /start / /stop / /restart <glob> — bulk actions, e.g. /restart gluetun-*, with per-container results aggregated into one message. Each match still runs through the existing guards, so a glob can't stop a protected container ([Feature] Disable the stop button? #38) or Docksentry itself.

Matching is case-insensitive over running + stopped containers; no glob chars → unchanged single/partial-name behaviour.

I deliberately left /check and /update out of this first cut — they hook into the batch-update + "Updates Available" snapshot flow, so glob there needs a bit more care (e.g. /update gluetun-* is a mass action that should go through the confirm/result path). Want me to do those next? If so, /check <glob> (scope a check to matches) is the safe one to start with. Give the /status/lifecycle globs a spin and let me know how they feel.

[amayer1983]

Follow-up shipped in v1.30.0 — went ahead and did /check and /update too, so #40 is now complete end-to-end:

• /check <name|glob> — scope a check, e.g. /check gluetun-* (shows the Updates-Available prompt for matches, or "up to date").
• /update <name|glob> — new command: checks, then updates only the matching containers that actually have an update, e.g. /update gluetun-*. Goes through the normal update path (group order, dependents cascade, health-check + rollback), so the /update gluetun-* mass action is as safe as "Update all" — typing the pattern is the confirmation.

So the full set now: /status, /check, /update, /start, /stop, /restart all take a glob. Bare /update shows usage. Give it a spin whenever — and thanks again for the idea, it turned into a genuinely handy power-user feature. 🙏

[LeeNX]

I can confirm this is working for my use-case. Did raise a bunch of more ideas, things like --help options, maybe given as -?

But I will open another feature request, if I forget the Telegram slash request.

Thanks @amayer1983