feat(github): add optional tag patterns for selective deployments

[hmh6a]

What is this PR about?

Adds an optional Tag patterns field to the GitHub On Tag trigger for applications and Docker Compose services. Each service can deploy only when a pushed tag matches one of its configured names or patterns. Leaving the field empty preserves the existing behavior: every tag triggers deployment.

Why this is needed

A monorepo can contain several independently deployed services. Today, a new tag triggers every service configured for On Tag in that repository, even when the release concerns only one service. This creates unnecessary builds and deployments.

Exact names alone are not sufficient for repeated releases because Git tag names must be unique. Patterns such as go-* allow successive releases (go-1, go-2, go-v1.2.3) without changing the Dokploy settings or reusing an existing tag. A shared pattern lets users release all services together when needed.

Example

For a repository containing three services:

Service	Tag patterns
Go API	all-*, go-*
Node service one	all-*, node-one-*
Node service two	all-*, node-two-*

• Push go-1 or go-2: deploy only the Go API.
• Push node-one-1: deploy only Node service one.
• Push all-1: deploy all three services.

The comma separates filters in Dokploy; the Git tag itself is a single name, such as go-2. The word all has no special meaning: it works because the same pattern is configured on each service.

Behavior and implementation

• Supports comma-separated exact names and * wildcards. * matches zero or more characters; all other characters are literal. Matching is case-sensitive and covers the entire tag name.
• Trims whitespace, removes duplicate entries, and includes an example below the field.
• Stores optional triggerTags arrays on applications and Compose services, with an additive database migration and generated Drizzle snapshot.
• Filters tag webhook targets before queueing or dispatching deployments and reports the matched service count.
• Ignores tag deletion events.
• Preserves existing behavior for empty filters and branch push triggers. Build/checkout behavior is unchanged; this change controls which services receive a tag-triggered deployment.

Validation

• 105 tests passed across tag matching, GitHub webhook routing, and affected application fixtures.
• pnpm -r run typecheck passed across all workspace projects.
• Applied the migration to the local instance and verified that settings persist after a browser reload.
• Replayed an actual go-1 webhook payload through the local HTTP endpoint: exactly one service was selected and its Docker deployment completed successfully.
• Shared all-* routing is covered by webhook tests. External webhook delivery was blocked by a timeout in the development proxy/Tailscale connection, so this is not claimed as a successful end-to-end public-webhook test.
• Validation ran with Node.js 25.9.0; the repository recommends 24.4.0. The full production build and full test suite were not run locally.

Checklist

• Created a dedicated branch based on the latest canary branch.
• Read the pull request guidance in CONTRIBUTING.md.
• Tested the change in a local instance.

Screenshots

The GitHub On Tag settings now include optional patterns and a versioned-tag example.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete correctness, security, migration, or persistence failures identified.

Summary

This PR adds optional, service-specific GitHub tag filters for applications and Compose services while preserving deploy-on-every-tag behavior when no filters are configured.

• Adds exact-name and anchored * wildcard matching.
• Persists tag patterns through application and Compose provider settings.
• Filters webhook deployment targets and ignores tag deletion events.
• Adds the corresponding database migration and focused routing and matcher tests.

_{Reviews (1) · Last reviewed commit: "feat(github): filter tag-triggered deplo..."}