Replies: 2 comments 1 reply
-
|
GitOps updates are triggered based on Git commits to the repository. So if you’re using the same repository for all your Git-based stacks, a single update will change the commit hash and trigger a redeployment for every stack linked to that repo. To avoid unintended redeployments, it’s recommended to split your repositories by service when using Git updates. |
Beta Was this translation helpful? Give feedback.
-
|
Oh so each commit triggers an update even when the files didn't change? - For example, if I change some meta files ( build pipeline.. ) and do a squash merge on a pull request, this will also update the untouched stack files? |
Beta Was this translation helpful? Give feedback.
-
|
Correct, because they are all looking at the same repos commit |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Ask a Question!
Hey folks,
I recently updated my Portainer-CE instances from
2.20version to the latest2.27.6-LTSversion.I've noticed some weird behavior with the old versions GitOps related:
Some stacks were randomly updated and even activated when I changed a single a stack file and pushed it. All affected stack files live in the same repository but were not changed. Are there any known issues related to this?
Beta Was this translation helpful? Give feedback.
All reactions