github-starred/komodo
2
0
Fork 1
mirror of https://github.com/moghtech/komodo.git synced 2026-03-09 07:13:36 -05:00
Code Issues 258 Packages Projects Releases 10 Wiki Activity

[Feature] Specify stack clone path #70

New Issue
Closed
opened 2025-10-31 15:01:21 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-10-31 15:01:21 -05:00
Owner
Copy Link

Originally created by @lighterless on GitHub (Oct 5, 2024).

I have multiple stacks that pull from the same repo and so currently it's cloning the same repo multiple times under /etc/komodo/stacks/{repo}/..

It would be nice if we could specify the stack clone path for each stack the same way we can for a repo.

image
Originally created by @lighterless on GitHub (Oct 5, 2024). I have multiple stacks that pull from the same repo and so currently it's cloning the same repo multiple times under `/etc/komodo/stacks/{repo}/..` It would be nice if we could specify the stack clone path for each stack the same way we can for a repo. <img width="814" alt="image" src="https://github.com/user-attachments/assets/354097a8-4cf4-4c16-88a4-46eacdea15b0">
GiteaMirror added the thinking 🤔 label 2025-10-31 15:01:21 -05:00
GiteaMirror commented 2025-10-31 15:01:22 -05:00
Author
Owner
Copy Link

@lighterless commented on GitHub (Oct 5, 2024):

I can workaround this by setting up a repo and then pointing the stacks to files on the server. That works but then I lose out on the git webhooks.

@lighterless commented on GitHub (Oct 5, 2024): I can workaround this by setting up a repo and then pointing the stacks to files on the server. That works but then I lose out on the git webhooks.
GiteaMirror commented 2025-10-31 15:01:22 -05:00
Author
Owner
Copy Link

@mbecker20 commented on GitHub (Oct 7, 2024):

If you use a shared Repo for compose files, you can still setup webhook by using Procedure. The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage: https://komo.do/docs/webhooks#procedure-webhooks.

It is an common situation though, and maybe something else can help here.

@mbecker20 commented on GitHub (Oct 7, 2024): If you use a shared Repo for compose files, you can still setup webhook by using Procedure. The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage: [https://komo.do/docs/webhooks#procedure-webhooks](https://komo.do/docs/webhooks#procedure-webhooks). It is an common situation though, and maybe something else can help here.
GiteaMirror commented 2025-10-31 15:01:22 -05:00
Author
Owner
Copy Link

@Malopieds commented on GitHub (Oct 8, 2024):

The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage

I'm using a shared repo with subfolder for each service. I have a procedure webhook that works but how do you only deploy the relevant stacks? Would you have an example of doing so? My services are redeployed no matter what file is changed. Am I missing something here? Should I do something in the repos part? Thank you for your help!

@Malopieds commented on GitHub (Oct 8, 2024): > The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage I'm using a shared repo with subfolder for each service. I have a procedure webhook that works but how do you only deploy the relevant stacks? Would you have an example of doing so? My services are redeployed no matter what file is changed. Am I missing something here? Should I do something in the repos part? Thank you for your help!
GiteaMirror commented 2025-10-31 15:01:23 -05:00
Author
Owner
Copy Link

@lighterless commented on GitHub (Oct 9, 2024):

If you use a shared Repo for compose files, you can still setup webhook by using Procedure. The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage: https://komo.do/docs/webhooks#procedure-webhooks.

It is an common situation though, and maybe something else can help here.

I tried that too but as @Malopieds mentions, it redeploys every stack regardless of which stack in the repo is updated.
For example I have a repo with a structure like this:

- services
  - actual
    - compose.yaml
  - adguardhome
    - compose.yaml
  - authelia
    - compose.yaml
  ...

Ideally only the stack that is updated is redeployed.

@lighterless commented on GitHub (Oct 9, 2024): > If you use a shared Repo for compose files, you can still setup webhook by using Procedure. The Procedure can PullRepo in the first stage, and deploy the relevant Stacks in the second stage: https://komo.do/docs/webhooks#procedure-webhooks. > > It is an common situation though, and maybe something else can help here. I tried that too but as @Malopieds mentions, it redeploys every stack regardless of which stack in the repo is updated. For example I have a repo with a structure like this: ``` - services - actual - compose.yaml - adguardhome - compose.yaml - authelia - compose.yaml ... ``` Ideally only the stack that is updated is redeployed.
GiteaMirror commented 2025-10-31 15:01:23 -05:00
Author
Owner
Copy Link

@mbecker20 commented on GitHub (Oct 9, 2024):

I have heard this use case a lot, when multiple stacks point to the same repo. I think the main solution here, like you mentioned, is to diff the "Deployed" files vs the "New" files, and if there aren't changes, you can skip the redeploy.

Already every Stack deploy reads the file contents it is deploying, and caches them to the database at Stack.info.deployed_contents. With this in place, doing the diff is straightforward at this point.

A new Core execution API for Stacks will help for this, called DeployStackIfChanged. I think providing this functionality can solve the problem internally for the webhook deploy case, and also gives to users the same logic to hook into inside Procedures (can just change DeployStack executions to DeployStackIfChanged executions).

@mbecker20 commented on GitHub (Oct 9, 2024): I have heard this use case a lot, when multiple stacks point to the same repo. I think the main solution here, like you mentioned, is to diff the "Deployed" files vs the "New" files, and if there aren't changes, you can skip the redeploy. Already every Stack deploy reads the file contents it is deploying, and caches them to the database at Stack.info.deployed_contents. With this in place, doing the diff is straightforward at this point. A new Core execution API for Stacks will help for this, called DeployStackIfChanged. I think providing this functionality can solve the problem internally for the webhook deploy case, and also gives to users the same logic to hook into inside Procedures (can just change DeployStack executions to DeployStackIfChanged executions).
GiteaMirror commented 2025-10-31 15:01:23 -05:00
Author
Owner
Copy Link

@lighterless commented on GitHub (Oct 13, 2024):

We are able to achieve this using a procedure and the DeployStackIfChanged action thanks to https://github.com/mbecker20/komodo/pull/117

@lighterless commented on GitHub (Oct 13, 2024): We are able to achieve this using a procedure and the DeployStackIfChanged action thanks to https://github.com/mbecker20/komodo/pull/117
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
1.19.0
1.19.1
1.19.2
1.19.3
1.19.4
bug
documentation
done
enhancement
help wanted
info
pull-request
Mirrored from GitHub Pull Request
 question
security
seen 👀
setup
thinking 🤔
ui
No Label thinking 🤔
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#70
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?