Describe the bug
wmill sync push removes objects that exist on the instance but not in the repository. Two things make this sharper than it first appears:
- Scripts are archived (recoverable). Variables and resources are hard-deleted (not recoverable). The CLI reports
Archiving for scripts; for variables it simply removes them — afterwards HTTP 404, list empty, nothing to restore.
- The two object types that carry secrets are opt-out, everything harmless is opt-in.
| Object type |
Included in push? |
| Scripts, flows, folders |
yes |
| Variables, resources |
yes — must be disabled with --skip-variables / --skip-resources |
| Schedules, triggers, users, groups |
no — must be enabled with --include-… |
To reproduce
- Create a resource on the instance that is not in the repo — e.g.
f/test/erp_access holding credentials, as one would when provisioning an instance.
- Run
wmill sync push --dry-run.
- resource f\test\erp_access.resource.yaml
- A real push removes it. The credentials are gone — not the code, not the automation, just the keys without which everything else stops.
The same applies to a variable created at runtime by a script:
- variable f\test\protocol.variable.yaml
Verified that --skip-variables --skip-resources removes the deletion line from the dry run, pushes flows through normally, and leaves the resource untouched (HTTP 200).
Expected behavior
Suggestions, roughly in order of preference:
- Make variables and resources opt-in like schedules and triggers, rather than opt-out.
- Or require explicit confirmation before deleting secret-bearing objects.
- Or archive them the way scripts are archived, so the operation is reversible.
Screenshots
No response
Browser information
Not applicable — reproduced via CLI.
Application version
CE v1.792.2, wmill CLI, self-hosted
Additional Context
There is also a quieter variant worth mentioning: if a script creates a variable at runtime — a counter, a cursor, a last-processed marker — that variable is deleted on the next deploy. Operational state stored in Windmill variables does not survive a push.
The dry run does show all of this reliably, so the workaround is to read every line starting with -. But the default ordering means the dangerous case is the one you get without asking for it.
Possibly related to #8468, which reported an accidental flow deletion via sync push. This report is about the variable/resource behaviour specifically, and about the archive-vs-hard-delete asymmetry.
Describe the bug
wmill sync pushremoves objects that exist on the instance but not in the repository. Two things make this sharper than it first appears:Archivingfor scripts; for variables it simply removes them — afterwardsHTTP 404, list empty, nothing to restore.--skip-variables/--skip-resources--include-…To reproduce
f/test/erp_accessholding credentials, as one would when provisioning an instance.wmill sync push --dry-run.The same applies to a variable created at runtime by a script:
Verified that
--skip-variables --skip-resourcesremoves the deletion line from the dry run, pushes flows through normally, and leaves the resource untouched (HTTP 200).Expected behavior
Suggestions, roughly in order of preference:
Screenshots
No response
Browser information
Not applicable — reproduced via CLI.
Application version
CE v1.792.2,
wmillCLI, self-hostedAdditional Context
There is also a quieter variant worth mentioning: if a script creates a variable at runtime — a counter, a cursor, a last-processed marker — that variable is deleted on the next deploy. Operational state stored in Windmill variables does not survive a push.
The dry run does show all of this reliably, so the workaround is to read every line starting with
-. But the default ordering means the dangerous case is the one you get without asking for it.Possibly related to #8468, which reported an accidental flow deletion via sync push. This report is about the variable/resource behaviour specifically, and about the archive-vs-hard-delete asymmetry.