`kars up` removes all pre-existing tags from the target resource group

[appliedi]

Summary

When kars up targets an existing resource group, it strips every tag from that group. Tags applied before the run are gone afterwards.

Version

@kars-runtime/cli@0.1.26

Reproduction

az group create -n <rg> -l <region> \
  --tags owner=someone environment=poc expiry=2026-11-30 cost-center=1234

az group show -n <rg> --query tags      # 4 tags

npx @kars-runtime/cli@0.1.26 up --resource-group <rg> ... --yes

az group show -n <rg> --query tags      # empty

Observed on every run, including runs that later failed for unrelated reasons — so the stripping happens early, around the step that logs Resource group '<rg>' ready.

Impact

• Cost attribution breaks. Tag-based cost allocation in Azure Cost Management silently stops working for the group.
• Governance tooling breaks. Policies and automation keyed on tags such as owner, expiry, environment or data-classification stop matching.
• Safety tooling can break closed. Teardown guards that assert an expected tag before permitting destructive operations will refuse to run after a deploy, which is the safe direction but still a surprise.

Azure resource-group tag updates are last-write-wins on a full replace, so a PUT that omits existing tags removes them. A merge (az group update --set tags.x=y, or the ARM equivalent) preserves them.

Suggested fix

When the resource group already exists, either leave its tags untouched or merge kars's own tags into the existing set rather than replacing it. If replacement is intentional, it should be documented and ideally opt-in.

[pallakatos]

Thanks Jess (@appliedi) — preserving customer resource-group metadata is required. We confirmed that the existing-resource-group path still unconditionally runs az group create; Azure treats the supplied tag set as the new complete set, so this can remove pre-existing tags. We are fixing this as part of the #515–#518 deployment-safety workstream by making the existing-group path read-only and adding a regression test that no tag-mutating command is emitted. We will report the verified behavior here.

[pallakatos]

Jess (@appliedi), the existing-resource-group tag-preservation fix is now available in draft #531 and its full CI/security matrix is green. A focused disposable test would be especially helpful:

az group create -n <disposable-rg> -l westus3 \
  --tags owner=someone environment=poc expiry=2026-11-30 cost-center=1234
az group show -n <disposable-rg> --query tags -o json

# Run the branch-built CLI from the instructions on #531
node dist/index.js up \
  --name tag-preservation-test \
  --region westus3 \
  --resource-group <disposable-rg> \
  --release v0.1.26 \
  --yes

az group show -n <disposable-rg> --query tags -o json

Please do not use a production group. The tag objects should remain identical even if a later deployment step fails. Remove the disposable group afterward and report any mismatch on #531 with identifiers redacted.

[pallakatos]

The draft fix is now available in #531 and the complete CI matrix is green. Existing resource groups are now handled without recreating them, and regression/live read-only tests confirm customer tags remain unchanged.

Jess (@appliedi), if practical, could you rerun against a pre-tagged disposable resource group and report whether all original tags survive? Feedback directly on #531 would be ideal.