fix: keep addon runtime files out of backups on existing repos - #2
Merged
Conversation
askb
force-pushed
the
fix/exclude-own-runtime-files
branch
from
July 12, 2026 08:29
8cd0b01 to
114a1ea
Compare
seed_gitignore() only writes a .gitignore when none exists, so any repo that already had one (every 'migrate an existing repo' case) never got the addon's own entries — .gitops_backup_status and gitops_backup.log were swept into backup PRs, risking the same status-file PR feedback loop as the #119 class of bug. Add ensure_own_excludes(): on every run against an existing repo, write the addon's runtime files to .git/info/exclude (git's local, uncommitted ignore — the right home for addon-managed metadata, independent of the user's committed .gitignore) and untrack them if a prior run committed them. Add a self-check covering the existing-.gitignore migration path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Anil Belur <abelur@linuxfoundation.org>
askb
force-pushed
the
fix/exclude-own-runtime-files
branch
from
July 12, 2026 08:30
114a1ea to
873dab4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
seed_gitignore()only writes a.gitignorewhen the repo doesn't already have one. When the addon is pointed at an existing git repo (the common "migrate my current config repo" case), that guard skips — so the addon's own runtime files are never ignored:.gitops_backup_status— the addon's status heartbeatgitops_backup.logBoth get swept into backup PRs (observed: haos-config#134 shipped
.gitops_backup_status+ parked integrations), and committing the status file risks the same daily-PR feedback loop the #119-class comment warns about. End users shouldn't have to hand-edit.gitignorefor the addon's own files.Fix
Add
ensure_own_excludes(), called on every run against an existing repo:.git/info/exclude— git's local, uncommitted ignore. It's the correct home for addon-managed metadata: independent of the user's committed.gitignore, works whether or not one exists, and never appears in a backup PR. Idempotent (managed block replaced each run)..gitops_backup_status/gitops_backup.logif a prior buggy run already committed them (removal flows out through the next backup PR).Test
Added self-check #4: a repo that already has its own
.gitignore(lacking the addon entries) and was never excluded — asserts the addon's runtime files stay out of the pushed backup branch while real drift is still backed up. All local self-checks pass; shellcheck clean.