Skip to content

Add --select flag to bundle config-remote-sync#5579

Open
ilyakuz-db wants to merge 1 commit into
mainfrom
feat/config-remote-sync-select
Open

Add --select flag to bundle config-remote-sync#5579
ilyakuz-db wants to merge 1 commit into
mainfrom
feat/config-remote-sync-select

Conversation

@ilyakuz-db

@ilyakuz-db ilyakuz-db commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Changes

Add an opt-in --select flag to the experimental bundle config-remote-sync command (hidden; used by DABs in the Workspace). The flag restricts detected, applied, and saved changes to explicitly named resources. It accepts the same selector grammar as bundle deploy --select (type.name or a unique short name), repeatable and/or comma-separated.

Default behavior without the flag is unchanged.

Implementation notes:

  • Selector resolution is shared with deploy via the extracted mutator.ResolveSelectors (the ResolveSelect mutator delegates to it), so the grammar and error messages cannot drift between the two commands.
  • Selection is plumbed separately from b.Select: that field is rejected for non-direct engines, while config-remote-sync supports both engines.
  • Filtering happens after planning (DetectChanges still plans the full resource set so ${resources.*} references resolve); only the emitted change set is restricted. Unlike deploy's plan filtering, the selection is deliberately not expanded to transitive dependencies — dependencies matter for planning, not for deciding which resources may be rewritten.
  • Permissions/grants sub-nodes follow their parent resource (they are the resource's own plan nodes, not dependencies).
  • A selected resource with no deployment-state entry emits nothing and exits 0, matching full-sync behavior for state-missing resources.
  • A selected dashboard still syncs lifecycle metadata such as etag; classifying such fields as ignore_remote_changes is tracked separately. Selection only limits which resources are written.

Why

A full sync diffs all resources in a bundle, so a drifted-but-unrelated resource (for example a dashboard whose etag changed remotely because someone opened the draft) can have unwanted changes written into its YAML while the user is syncing a different resource. The Workspace UI knows which resource the user is editing; passing it via --select limits the blast radius of one sync run to that resource.

Tests

  • New unit tests for selector resolution and change-map filtering in bundle/configsync.
  • 11 new acceptance directories under acceptance/bundle/config-remote-sync/ covering: basic selection, idempotency, and no lost updates; cross-resource ${resources.*.id} references; a job+dashboard bundle where selecting the job never touches the dashboard YAML (and the inverse); selector errors (unknown, malformed, ambiguous); selecting a never-deployed resource; two resources sharing one YAML file; multiple, comma-separated, and repeated selections; JSON output shape; variable restoration under selection; target overrides; missing-snapshot error parity with and without the flag.
  • All new directories pass on both engines (direct and terraform) locally and against a real Unity Catalog workspace (cloud acceptance run: all new directories plus the cross-resource canary directories cli_defaults, multiple_resources, multiple_files, job_pipeline_task, resolve_variables — every variant passed on both engines). The entire existing config-remote-sync acceptance tree passes unchanged on both engines — the flag is opt-in and no existing goldens were modified. The deploy --select acceptance tree is also unaffected by the ResolveSelectors extraction.

Add an opt-in --select flag to the experimental `bundle config-remote-sync`
command that restricts detected, applied, and saved changes to explicitly
named resources. The selector grammar is shared with `bundle deploy --select`
("type.name" or a unique short name) via the extracted
mutator.ResolveSelectors helper, so the two commands cannot drift apart.

Selection is plumbed separately from b.Select because that field is rejected
for non-direct engines, while config-remote-sync supports both engines.
Filtering happens after planning so ${resources.*} reference resolution is
unaffected; only the emitted changes are restricted. Default behavior without
the flag is unchanged.

This limits the blast radius of a sync run: a user syncing one resource can
no longer have an unrelated drifted resource (e.g. a dashboard whose etag
changed remotely) rewritten in the same run.
@ilyakuz-db ilyakuz-db marked this pull request as ready for review June 12, 2026 19:00
@github-actions

Copy link
Copy Markdown
Contributor

Approval status: pending

/acceptance/bundle/ - needs approval

60 files changed
Suggested: @denik
Also eligible: @pietern, @janniklasrose, @andrewnester, @shreyas-goenka, @anton-107, @lennartkats-db

/bundle/ - needs approval

Files: bundle/config/mutator/resolve_select.go, bundle/configsync/select.go, bundle/configsync/select_test.go
Suggested: @denik
Also eligible: @pietern, @janniklasrose, @andrewnester, @shreyas-goenka, @anton-107, @lennartkats-db

/cmd/bundle/ - needs approval

Files: cmd/bundle/config_remote_sync.go
Suggested: @denik
Also eligible: @pietern, @janniklasrose, @andrewnester, @shreyas-goenka, @anton-107, @lennartkats-db

General files (require maintainer)

Files: NEXT_CHANGELOG.md
Based on git history:

  • @denik -- recent work in bundle/configsync/, ./, bundle/config/mutator/

Any maintainer (@andrewnester, @anton-107, @denik, @pietern, @shreyas-goenka, @simonfaltum, @renaudhartert-db) can approve all areas.
See OWNERS for ownership rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant