feat(github): add optional tag patterns for selective deployments by hmh6a · Pull Request #5472 · Dokploy/dokploy

hmh6a · 2026-09-16T22:18:24Z

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 names and glob patterns through the existing micromatch dependency with { bash: true }, without custom escaping. Matching is case-sensitive and covers the entire tag name. The documented go-*, *-prod, and exact-name examples remain supported.
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.
Keeps the triggering tag name in application and Compose deployment history alongside the original full commit hash. The tag remains visible after the title changes to the commit message. The UI renders the description directly with preserved line breaks. Non-tag deployment descriptions retain their original Commit: <hash> behavior. No separate tag SHA or shortened commit is added.
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

Latest revision: 77 focused tests passed across tag matching and GitHub webhook routing. Removed the generic description helper and its tests, and reduced matching tests to the supported behavior.
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.

GitHub On Tag settings with optional all-* and go-* patterns and versioned tag examples

The deployment history retains the triggering tag (all-6 or go-7) alongside the existing commit message and full commit hash.

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..."}

hmh6a · 2026-09-19T05:53:34Z

Updated in c0cbea0 and 1de45f3.

The tag matcher now reuses the existing micromatch dependency as requested. Non-star glob characters remain literal, and regression tests cover slashes, dot-prefixed names, and special characters. Empty filters still deploy on every tag.

I also added the triggering tag name to application and Compose deployment history. This helps identify which release triggered each service in a monorepo. The existing commit message and full commit hash remain unchanged; the tag is shown only once while running and is retained after completion. No separate tag SHA or shortened commit is displayed. Build/checkout behavior is unchanged.

Validation: 90 focused tests passed, and pnpm -r run typecheck passed across the workspace. The screenshots below are from the local instance. A full production build and full test suite were not run for this revision.

Optional tag patterns

Tag names in deployment history

Ready for another review. Thank you!

narcisonunez · 2026-09-29T13:57:43Z

 				await updateDeployment(deployment.deploymentId, {
 					title: commitInfo.message,
-					description: `Commit: ${commitInfo.hash}`,
+					description: getDeploymentCommitDescription(


This changes the deployment description for every deployment, not just tag-triggered ones. Before, the finally block always wrote Commit: <hash>. Now any descriptionLog that isn't Hash: <same hash> is kept in front of it. For example:

manual/API deploys with input.description → "<desc>\nCommit: …"

project transfers (transfer.ts) → "Transferred to X\nCommit: …"

compose [refreshToken] webhooks with an empty or "NEW COMMIT" hash (GitLab/Bitbucket/Gitea fallback) → "Hash: NEW COMMIT\nCommit: …"

That's outside the scope of this PR. Could we limit it to the tag case and drop the helper?

For example:

description: descriptionLog.startsWith("Tag: ") ? `${descriptionLog}\nCommit: ${commitInfo.hash}` : `Commit: ${commitInfo.hash}`,

Then deployment-description.ts and its test can be removed, and every other deployment behaves exactly as it does today

narcisonunez · 2026-09-29T13:58:03Z

 				await updateDeployment(deployment.deploymentId, {
 					title: commitInfo.message,
-					description: `Commit: ${commitInfo.hash}`,
+					description: getDeploymentCommitDescription(


Same as in application.ts: please apply the same tag-only condition here

narcisonunez · 2026-09-29T14:00:25Z

 							const isExpanded = expandedDescriptions.has(
 								deployment.deploymentId,
 							);
+							const descriptionText = (deployment.description ?? "")


Two things here:

text.startsWith("Tag SHA:") (L292) is dead code. Nothing writes a Tag SHA: line anymore, so it looks left over. Check this

Hiding the Tag: X line when the title is Tag created: X only prevents a duplicate for the minute or so the deployment is running. It also ties the UI to the exact strings the webhook produces.

I'd remove the whole split/filter/join block and render deployment.description directly. Keeping whitespace-pre-wrap on the span (L357 Check couple lines below) is enough for the multi-line description.

narcisonunez · 2026-09-29T14:05:32Z

+/** Match the entire tag, treating only * as a wildcard (zero or more characters). */
+export function matchesTagPattern(tag: string, pattern: string): boolean {
+	// Keep non-star glob syntax literal to preserve the existing tag filter contract.
+	const glob = pattern.replace(/[\\?[\]{}()!+@|^$"]/g, "\\$&");


Thanks for switching to micromatch! But escaping every glob character except * cancels most of the benefit: we end up with an escape regex, three options and a large test table that mostly tests the escaping. shouldDeploy (packages/server/src/utils/watch-paths/should-deploy.ts) uses plain micromatch globs for watch paths, and tag patterns should work the same way:

export const matchesTriggerTags = (tag: string, patterns?: string[] | null) => !patterns?.length || micromatch.isMatch(tag, patterns, { bash: true });

This gives the same result for every documented case (go-*, *-prod, ab*ab, literal v1.2, case-sensitive, full match). The only difference is that ?, {a,b} and ! also work as globs, which is what users would expect. matchesTagPattern can be removed, and the test table can be reduced to the behavior we actually document.

feat(github): filter tag-triggered deployments by optional patterns

052d8a7

hmh6a requested a review from Siumauricio as a code owner September 16, 2026 22:18

narcisonunez reviewed Sep 18, 2026

View reviewed changes

Comment thread apps/dokploy/utils/tag-triggers.ts Outdated

hmh6a added 2 commits September 19, 2026 08:52

refactor(github): reuse micromatch for tag filters

c0cbea0

feat(deployments): retain triggering tag in deployment history

1de45f3

hmh6a requested a review from narcisonunez September 19, 2026 05:54

narcisonunez requested changes Sep 29, 2026

View reviewed changes

narcisonunez added the requested-changes label Sep 29, 2026

fix(github): simplify tag matching and scope deployment metadata

db065e1

Navigation Menu

Uh oh!

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

feat(github): add optional tag patterns for selective deployments#5472
hmh6a wants to merge 4 commits into
Dokploy:canaryfrom
hmh6a:codex/optional-tag-trigger-filter

hmh6a commented Sep 16, 2026 •

edited

Loading

Uh oh!

Uh oh!

hmh6a commented Sep 19, 2026

Uh oh!

narcisonunez Sep 29, 2026

Uh oh!

narcisonunez Sep 29, 2026

Uh oh!

narcisonunez Sep 29, 2026

Uh oh!

narcisonunez Sep 29, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

hmh6a commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is this PR about?

Why this is needed

Example

Behavior and implementation

Validation

Checklist

Screenshots

Confidence Score: 5/5

Summary

Uh oh!

Uh oh!

hmh6a commented Sep 19, 2026

Uh oh!

narcisonunez Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

narcisonunez Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

narcisonunez Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

narcisonunez Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hmh6a commented Sep 16, 2026 •

edited

Loading