[GH-ISSUE #458] [Feature] For git stacks, add ability to test changes made in the UI before having to commit #3341

New Issue

GiteaMirror · 2026-04-13T14:57:17-05:00

GiteaMirror commented

2026-04-13 14:57:17 -05:00

Originally created by @pelluch on GitHub (Apr 28, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/458

First of all, awesome software, and I appreciate all the work you've done.

Currently, if a stack is configured via a git repository, and I make changes to the compose file through the UI, there doesn't seem to a be a way to test them without saving the stack, which triggers a commit and a push. This can pollute the git repository if the change doesn't behave as expected.

From what I can tell, the only way to do so would be to manually edit the local compose file on the target server itself, and then running a docker compose up -d - and this has to be done when Poll for Updates is disabled, because otherwise the changes done will shortly be replaced by Komodo. This certainly works, but is a bit tedious and requires me to SSH to the machine.

I would find it quite useful if there was an option to effectuate changes in the UI and test them before having to commit to git (which would probably also require to disable polling of the git repository). If this were done, it would probably be useful to have some sort of icon or indicator that made it very obvious this stack had "unsynced" changes. When done testing, we could finally commit (I've +1'ed this feature request to allow custom title / description to the commits as well).

Originally created by @pelluch on GitHub (Apr 28, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/458 First of all, awesome software, and I appreciate all the work you've done. Currently, if a stack is configured via a git repository, and I make changes to the compose file through the UI, there doesn't seem to a be a way to test them without saving the stack, which triggers a commit and a push. This can pollute the git repository if the change doesn't behave as expected. From what I can tell, the only way to do so would be to manually edit the local compose file on the target server itself, and then running a `docker compose up -d` - and this has to be done when Poll for Updates is disabled, because otherwise the changes done will shortly be replaced by Komodo. This certainly works, but is a bit tedious and requires me to SSH to the machine. I would find it quite useful if there was an option to effectuate changes in the UI and test them before having to commit to git (which would probably also require to disable polling of the git repository). If this were done, it would probably be useful to have some sort of icon or indicator that made it very obvious this stack had "unsynced" changes. When done testing, we could finally commit (I've +1'ed [this](https://github.com/moghtech/komodo/issues/137) feature request to allow custom title / description to the commits as well).

GiteaMirror added the enhancement label 2026-04-13 14:57:17 -05:00

GiteaMirror commented

2026-04-13 14:57:18 -05:00

@mbecker20 commented on GitHub (Apr 29, 2025):

I think this flow would be complicated to implement, and there is a more idiomatic solution in using a temporary branch to test in, and before merging back to main in PR. There is also the ui defined and files on server modes which are both well suited to testing before finalizing in git.

@mbecker20 commented on GitHub (Apr 29, 2025): I think this flow would be complicated to implement, and there is a more idiomatic solution in using a temporary branch to test in, and before merging back to main in PR. There is also the ui defined and files on server modes which are both well suited to testing before finalizing in git.

GiteaMirror commented

2026-04-13 14:57:19 -05:00

@adrianipopescu commented on GitHub (Apr 30, 2025):

imo this could be solved by just adding a "recompose" option instead of redeploy, but could require pre and post actions, or better, a tick to run existing pre/post deploy actions

@adrianipopescu commented on GitHub (Apr 30, 2025): imo this could be solved by just adding a "recompose" option instead of redeploy, but could require pre and post actions, or better, a tick to run existing pre/post deploy actions

GiteaMirror commented

2026-04-13 14:57:19 -05:00

@TerrifiedBug commented on GitHub (May 10, 2025):

Is adding a commit necessarily a bad thing? It could be useful for tracking what worked and what didn't, no?

@TerrifiedBug commented on GitHub (May 10, 2025): Is adding a commit necessarily a bad thing? It could be useful for tracking what worked and what didn't, no?

GiteaMirror commented

2026-04-13 14:57:19 -05:00

@adrianipopescu commented on GitHub (May 11, 2025):

if you work with branches and merge requests, no -- if you don't, ocd types like me have issues with junk in the repo, but I can live with it

@adrianipopescu commented on GitHub (May 11, 2025): if you work with branches and merge requests, no -- if you don't, ocd types like me have issues with junk in the repo, but I can live with it

GiteaMirror commented

2026-04-13 14:57:20 -05:00

@oblivioncth commented on GitHub (Jun 10, 2025):

It's not like there's a trivial way to switch branches within Komodo anyway. There is the terminal but its on another page, won't default to the directory of the stack you're working on, at at least on docker it's a bit jank sometimes (e.g. ls not working without arguments, inability to use arrow up to get last command).

Being able to make changes to redeploy with until you get them where you want them makes sense to me as that's how I'd handle it if done outside of Komodo with external tools anyway. I imagine that's how many people use Git in general. Sure you make mistakes, and when you do there's debate on whether you keep the commits or amend if you're on a branch, but I imagine most people dont just blindly commit testing changes that they're not even remotely confident are right... at least I wouldn't! A bit of instant feedback on the active machine is better for that. To me I rely on CI as the second measure in "measure twice, cut once", not the first. The first is local testing and like @adrianipopescu I don't want to bloat my repo with stuff I'm just tossing around.

Plus it would be nice if there was better git integration with monorepos where if you use the Git Repo option the repository isn't cloned for every stack you make and is instead kept in sync between them. Unless that's been changed, I believe this only way to do this is using the Repos feature separately and "Files on Server" for stacks, but then the git integration at the stack level isn't quite as tight. Though I digress, that's a seperate issue.

Overall, it's a moonshot and asking for A LOT, but in my eyes this tool has massive potential for acting as a minimal, but "fully functional" git development environment for docker in the long run. Web hooks already let you keep up with external changes, if the git integration was just a bit more fleshed out so that regardless of monorepo or not you could make changes locally, test them as many times as needed, and then when you're done make a proper commit and push, all from within komodo, that wound be simply beautiful. Just throw in a convenient terminal button on the stacks screen (or some kind of drop-down/pull-up) that opens a host (i.e. real host or komodo container) terminal defaulted to the CWD of the stack file so you can even easily switch branches and perform other git actions directly if you want and I can think of few reasons to ever need to leave Komodo for docker development/management. Bonus points if it's like "git bash for windows" where the current branch is displayed and the output is colorized.

Think super miniature VS code built-in. To be fair, we could nearly get this functionality right now by adding a VSCode sidecar and switching back and forth, but having it all and one would be a killer feature.

I'm just rambling at this point, and not trying to imply all of this is easy, but in some ways Komodo is already not that far off from being able to do this,. It's git integration is pretty good already, it's just missing some coverage for certain workflows (e.g. this issue) and some polish.

Just an exciting prospect is all :)

@oblivioncth commented on GitHub (Jun 10, 2025): It's not like there's a trivial way to switch branches within Komodo anyway. There is the terminal but its on another page, won't default to the directory of the stack you're working on, at at least on docker it's a bit jank sometimes (e.g. `ls` not working without arguments, inability to use arrow up to get last command). Being able to make changes to redeploy with until you get them where you want them makes sense to me as that's how I'd handle it if done outside of Komodo with external tools anyway. I imagine that's how many people use Git in general. Sure you make mistakes, and when you do there's debate on whether you keep the commits or amend if you're on a branch, but I imagine most people dont just blindly commit testing changes that they're not even remotely confident are right... at least I wouldn't! A bit of instant feedback on the active machine is better for that. To me I rely on CI as the second measure in "measure twice, cut once", not the first. The first is local testing and like @adrianipopescu I don't want to bloat my repo with stuff I'm just tossing around. Plus it would be nice if there was better git integration with monorepos where if you use the Git Repo option the repository isn't cloned for every stack you make and is instead kept in sync between them. Unless that's been changed, I believe this only way to do this is using the Repos feature separately and "Files on Server" for stacks, but then the git integration at the stack level isn't quite as tight. Though I digress, that's a seperate issue. Overall, it's a moonshot and asking for A LOT, but in my eyes this tool has massive potential for acting as a minimal, but "fully functional" git development environment for docker in the long run. Web hooks already let you keep up with external changes, if the git integration was just a bit more fleshed out so that regardless of monorepo or not you could make changes locally, test them as many times as needed, and then when you're done make a proper commit and push, all from within komodo, that wound be simply beautiful. Just throw in a convenient terminal button on the stacks screen (or some kind of drop-down/pull-up) that opens a host (i.e. real host or komodo container) terminal defaulted to the CWD of the stack file so you can even easily switch branches and perform other git actions directly if you want and I can think of few reasons to ever need to leave Komodo for docker development/management. Bonus points if it's like "git bash for windows" where the current branch is displayed and the output is colorized. Think super miniature VS code built-in. To be fair, we could nearly get this functionality right now by adding a VSCode sidecar and switching back and forth, but having it all and one would be a killer feature. I'm just rambling at this point, and not trying to imply all of this is easy, but in some ways Komodo is already not that far off from being able to do this,. It's git integration is pretty good already, it's just missing some coverage for certain workflows (e.g. this issue) and some polish. Just an exciting prospect is all :)

GiteaMirror commented

2026-04-13 14:57:20 -05:00

@oblivioncth commented on GitHub (Jun 11, 2025):

I'm not sure, but after some brief testing an examining the repo history, it seems that the repo-cache mechanism might have been added after #100 was closed and the problem of cloning the same repository over and over if referencing the same one through multiple stacks no longer exists.

If so, this does highlight one of the particular challenges with this Issue.

Currently one cache per repo/branch is kept and if you edit any stack and save the repo is immediately updated. But if this workflow is supported, how does one handle the situation where:

Stack A from REPO is edited and saved, but not synced with git
Stack B from REPO is then edited and synced with git

What happens to the changes on stack A? Do they get inadvertently included with the changes of Stack B since they're from the same repo and the user just need to know this?

I think it would be ideal if they stay separate, i.e. the changes for A aren't committed at all so that B changes don't affect A and in theory the B changes could get committed/pushed on their own while the working changes to A remain, but this introduces another hurdle as what do you do with the working changes to A since both are using the same repo directory? Does Komodo silently git stash/git stash pop in the background? But then what happens if multiple sessions/users are working with the repo at once?

Definitely tricky, but certainly can be done. One approach could be some form on indirection, where the uncommitted changes to A are actually made to a hidden file stored outside the repo (as to not effect git), and only once the user hits Commit/Push in the UI do the proxied changes actually replace the original compose.yaml in the repo and are immediately committed and/or pushed. Each time the container is interacted with through the UI or backend, Komodo would check to see if a proxied file for the stack exists (i.e. there are active edits for the file) and simply defer to the proxy if so; otherwise, it uses the original file as it does now.

Of course, there would need to be handling for if the repo was updated since editing the file started and the "base" compose.yaml has now diverged, but some kind of simple dialogue that asks "Reset to updated commit or ignore and keep current edits?" would suffice. A more advance feature would be to offer a third choice that automatically merges the file contents to bring the proxied file up-to-date with the new original, and then if conflicts occur, either implement a singular file conflict resolution UI (yes I know, even more work of course) or simply tell the user they need to fix the problem externally on their own externally and then just lock edits to that stack until they do so.

It can certainly get complicated, but some level of support for this workflow should be feasible (at least in the long run), especially if you only stick to "Drop changes"/"Ignore changes" options if the repo updates after editing started.

@oblivioncth commented on GitHub (Jun 11, 2025): I'm not sure, but after some brief testing an examining the repo history, it seems that the `repo-cache` mechanism might have been added after #100 was closed and the problem of cloning the same repository over and over if referencing the same one through multiple stacks no longer exists. If so, this does highlight one of the particular challenges with this Issue. Currently one cache per repo/branch is kept and if you edit any stack and save the repo is immediately updated. But if this workflow is supported, how does one handle the situation where: 1) Stack A from REPO is edited and saved, but not synced with git 2) Stack B from REPO is then edited and synced with git What happens to the changes on stack A? Do they get inadvertently included with the changes of Stack B since they're from the same repo and the user just need to know this? I think it would be ideal if they stay separate, i.e. the changes for A aren't committed at all so that B changes don't affect A and in theory the B changes could get committed/pushed on their own while the working changes to A remain, but this introduces another hurdle as what do you do with the working changes to A since both are using the same repo directory? Does Komodo silently `git stash`/`git stash pop` in the background? But then what happens if multiple sessions/users are working with the repo at once? Definitely tricky, but certainly can be done. One approach could be some form on indirection, where the uncommitted changes to A are actually made to a hidden file stored outside the repo (as to not effect git), and only once the user hits Commit/Push in the UI do the proxied changes actually replace the original `compose.yaml` in the repo and are immediately committed and/or pushed. Each time the container is interacted with through the UI or backend, Komodo would check to see if a proxied file for the stack exists (i.e. there are active edits for the file) and simply defer to the proxy if so; otherwise, it uses the original file as it does now. Of course, there would need to be handling for if the repo was updated since editing the file started and the "base" compose.yaml has now diverged, but some kind of simple dialogue that asks "Reset to updated commit or ignore and keep current edits?" would suffice. A more advance feature would be to offer a third choice that automatically merges the file contents to bring the proxied file up-to-date with the new original, and then if conflicts occur, either implement a singular file conflict resolution UI (yes I know, even more work of course) or simply tell the user they need to fix the problem externally on their own externally and then just lock edits to that stack until they do so. It can certainly get complicated, but some level of support for this workflow should be feasible (at least in the long run), especially if you only stick to "Drop changes"/"Ignore changes" options if the repo updates after editing started.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#3341