acharcharA
Windmill•2mo ago•
19 replies
acharchar

Git Promotion Obstacle

Background


We are using the Git Promotion workflow with a single repository and two long-lived branches: 
staging
 and 
main
.

- The de-staging workspace is linked to the 
staging
 branch.
- The de-prod workspace is linked to the 
main
 branch.
- In the de-staging workspace, we promote changes by targeting the 
main
 branch.
- In de-prod, developers are set as operators with additional privileges to create resources and variables that are intentionally not managed by Git sync.

Intended Development Flow


1. A developer makes changes in the de-staging workspace UI.
2. Windmill creates a commit on the 
staging
 branch via "deploy".
3. A GitHub Action opens a PR from 
staging
 → 
main
.
4. The PR is reviewed and merged into 
main
.
5. The 
main
 branch is synced to de-prod using 
wmill sync push --workspace de-prod
.

Issue


We are seeing files “ping-pong” between environments. After a change is made in de-staging and merged into 
main
, the same file appears in de-staging as out of sync. Exposed via the "preview" option.

Questions


1. Is there a reference Git Promotion example repository or a recommended workflow for this pattern? We are currently using push-on-merge found in a repo (possibly incorrect for this workflow). This action does not sync the workspace because the commit message starts with [WM]. We locally sync the workspace after pulling origin/main, hence item 5 (above)
2. Is there a Windmill lock file that may need to be rebased or reset to prevent this drift?
Was this page helpful?