Flapping sync #1267

Closed
opened 2026-03-22 17:16:57 -05:00 by GiteaMirror · 9 comments
Owner

Originally created by @june012006 on GitHub (Jul 5, 2025).

I have a resource sync with gitea, and one of the stacks being synced keeps flapping between removing environment variables and adding them. If I "execute sync" while the variables are in the stack, it will remove them, if they aren't there, it will re-add them. The git repo has them. The toml file being synced is a exact copy of the one in komodo. As I'm using interpolated variables, there's no need to sanitize it, and so here is the exact toml file. It is the two ESP_* variables that it wants to add or remove.

name = "homeassistant"
tags = [
  "git",
  "Smart-Home",
  "Infrastructure",
  "gitea",
  "renovate"
]
[stack.config]
server = "gpu1"
files_on_host = true
run_directory = "/etc/komodo/repos/renovated_docker_compose/docker-compose/homeassistant"
additional_env_files = ["secrets.yaml"]
pre_deploy.command = """
groupadd -fg 1883 mosquitto
id -u mosquitto &>/dev/null || useradd -u 1883 -g 1883 mosquitto
chown -R mosquitto: /opt/mosquitto
chown 1000:1000 /opt/nodered
"""
environment = """
FQDN=[[FQDN]]
ESP_UN=[[ESP_UN]]
ESP_PW=[[ESP_PW]]
""" ```
Originally created by @june012006 on GitHub (Jul 5, 2025). I have a resource sync with gitea, and one of the stacks being synced keeps flapping between removing environment variables and adding them. If I "execute sync" while the variables are in the stack, it will remove them, if they aren't there, it will re-add them. The git repo has them. The toml file being synced is a exact copy of the one in komodo. As I'm using interpolated variables, there's no need to sanitize it, and so here is the exact toml file. It is the two ESP_* variables that it wants to add or remove. ``` [[stack]] name = "homeassistant" tags = [ "git", "Smart-Home", "Infrastructure", "gitea", "renovate" ] [stack.config] server = "gpu1" files_on_host = true run_directory = "/etc/komodo/repos/renovated_docker_compose/docker-compose/homeassistant" additional_env_files = ["secrets.yaml"] pre_deploy.command = """ groupadd -fg 1883 mosquitto id -u mosquitto &>/dev/null || useradd -u 1883 -g 1883 mosquitto chown -R mosquitto: /opt/mosquitto chown 1000:1000 /opt/nodered """ environment = """ FQDN=[[FQDN]] ESP_UN=[[ESP_UN]] ESP_PW=[[ESP_PW]] """ ```
Author
Owner

@june012006 commented on GitHub (Jul 5, 2025):

The last 3 backticks are there because I was trying to close out the code formatting.

@june012006 commented on GitHub (Jul 5, 2025): The last 3 backticks are there because I was trying to close out the code formatting.
Author
Owner

@mbecker20 commented on GitHub (Jul 5, 2025):

That is strange, and I cannot reproduce it syncing that same TOML. It just syncs the variables in and keeps them.
What does the Info tab show? Do you see the variables in the TOML there?

Also, you use additional_env_files = ["secrets.yaml"]. Not really related, but I don't know about this, does this work to pass --env-file secrets.yaml?

@mbecker20 commented on GitHub (Jul 5, 2025): That is strange, and I cannot reproduce it syncing that same TOML. It just syncs the variables in and keeps them. What does the Info tab show? Do you see the variables in the TOML there? Also, you use `additional_env_files = ["secrets.yaml"]`. Not really related, but I don't know about this, does this work to pass `--env-file secrets.yaml`?
Author
Owner

@june012006 commented on GitHub (Jul 6, 2025):

Info in the sync? Shows the file name. Info tab in the stack, under deployed config, shows all values appropriately, at least while it has that version.
The sync can never go green, as if it is synced correctly, with the variables in place, it will show that it needs to remove them. After the sync, it shows a new sync to add them back. The variables do get removed, or added exactly as it says it will, but it won't recognize the correct state when it achieves it. If it'll help, i can get some screenshots in the morning

Regarding the secrets.yaml, yes it works well. Has to be formatted as yaml ofc, but docker compose treats it like an env file. I use sops to encrypt before i push to my repo, and set komodo to run a decrypt script after each repo pull.

@june012006 commented on GitHub (Jul 6, 2025): Info in the sync? Shows the file name. Info tab in the stack, under deployed config, shows all values appropriately, at least while it has that version. The sync can never go green, as if it is synced correctly, with the variables in place, it will show that it needs to remove them. After the sync, it shows a new sync to add them back. The variables do get removed, or added exactly as it says it will, but it won't recognize the correct state when it achieves it. If it'll help, i can get some screenshots in the morning Regarding the secrets.yaml, yes it works well. Has to be formatted as yaml ofc, but docker compose treats it like an env file. I use sops to encrypt before i push to my repo, and set komodo to run a decrypt script after each repo pull.
Author
Owner

@mbecker20 commented on GitHub (Jul 10, 2025):

In the Info tab is shows the toml file it is using to source the sync. In this location, are the variables there? Is it changing between syncs?

@mbecker20 commented on GitHub (Jul 10, 2025): In the Info tab is shows the toml file it is using to source the sync. In this location, are the variables there? Is it changing between syncs?
Author
Owner

@june012006 commented on GitHub (Jul 11, 2025):

Yes, the variables show are there in the info tab. That part never changes.

@june012006 commented on GitHub (Jul 11, 2025): Yes, the variables show are there in the info tab. That part never changes.
Author
Owner

@june012006 commented on GitHub (Jul 11, 2025):

I haven't figured out why, but the linked repo, and only that one (I have one per server of the same thing) has a cloned hash and a latest hash, persistently. Not sure why though. The cloned hash lacks the variables, and the latest has them. Not sure why it is switching though

@june012006 commented on GitHub (Jul 11, 2025): I haven't figured out why, but the linked repo, and only that one (I have one per server of the same thing) has a cloned hash and a latest hash, persistently. Not sure why though. The cloned hash lacks the variables, and the latest has them. Not sure why it is switching though
Author
Owner

@june012006 commented on GitHub (Jul 18, 2025):

I now have two different entries for the same stack update, neither match the current repo state.

@june012006 commented on GitHub (Jul 18, 2025): I now have two different entries for the same stack update, neither match the current repo state.
Author
Owner

@june012006 commented on GitHub (Jul 18, 2025):

Forget all of that, I had a duplicate of my configuration toml.

@june012006 commented on GitHub (Jul 18, 2025): Forget all of that, I had a duplicate of my configuration toml.
Author
Owner

@mbecker20 commented on GitHub (Jul 19, 2025):

Glad you were able to figure it out, I really had no clue what was going on.

@mbecker20 commented on GitHub (Jul 19, 2025): Glad you were able to figure it out, I really had no clue what was going on.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#1267