Staying in sync
I've read through the docs on git sync and wmill cli sync. I have wmill syncing working. When I make changes via the wmill UI, if I want them in my local copy of the workspace I run wmill sync pull. If I make changes to the local workspace, I run wmill sync push, approve the diff and the changes go back to the wmill workspace storage. If I look at the history of a changed file, I see the history of changes. Now I want this workspace to also be synced to a git repo and I have some questions:
If I add git sync to the workspace, do I also need to clone the repo to work locally or do I just use wmill cli for local work and push changes back to the workspace?
For git sync, what if changes happen to the repo outside of wmill, how do I get wmill to pull the latest code from the repo?
Is the git sync more tied to deploys instead of draft saves? In other words, saving drafts keeps history of those changes between saves, deploying pushes to the git repo, tracking history between deploys?
Thanks for the help,
-Chris
10 Replies
Hi Chris, correct draft is something that is UI only
deploy erase previous draft
We have a similar setup. We have a gitlab job that runs wmill sync push whenever the code in the repo has changed.
That only works if the repo is the single source of truth of course. Changes made only in the UI will be overwritten.
We have a local windmill instance where we push the current code to, make changes in the UI, pull the workspace and then git push to a MR.
So you don't have git sync enabled in the workspace?
No, that didn't fit with our workflow
Windmill's git flow has the UI as the single source of truth. That wasn't compatible with our monorepo where windmill is just one of many apps.
So to get code into your workspace you have two options ... wmill sync push OR git push?
Since you said you have a job that does the wmill sync push when the repo changes?
But if you directly wmill sync push, without doing a git commit + push, then someone else does a git push, your workspace code changes are gone (but still available locally if you have not done a wmill sync pull).
Correct. That's why we never manually sync push to our production windmill. Only the gitlab job is allowed to do that.
So you could accomplish the same with a single public-internet-accessible install of windmill by just using two workspaces.
All your work would happen in the dev workspace while your gitlab job would sync push to the prod workspace.
probably, not sure about how the changes in the dev workspace are pushed to git though. with git sync?
Same way - you make your changes in the dev workspace, via UI or local and keep local synced via wmill cli. Once you're ready you git commit + push that local folder to branch in git, PR it, then merge into prod branch which would have a job that would wmill sync it to prod workspace.
Okay. You can achieve the same without the prod branch. Just create two different manual stages/jobs so that you can deploy your changes to both environments. No need for additional branches and PRs that way.
See: https://trunkbaseddevelopment.com/