Document and test Git-hosted root self-configuration

[cooktheryan]

FetchIt already accepts a Git-hosted root YAML through FETCHIT_CONFIG_URL, applies its independently scheduled methods, and updates its own configuration through configReload. The documentation did not present that workflow as a complete per-host entry point, leaving the app-of-apps use case unclear.

Add a guide with a per-host repository layout, a root referencing multiple workload repositories/methods, bootstrap without a local config, recurring self-reconfiguration, private-root authentication limits, writable mount requirements, and root/workload trust boundaries. Explicitly distinguish this existing workflow from recursive child-YAML imports and Argo CD resource handling. No new configuration schema, composition, or runtime behavior is introduced.

Add a production-image integration test to CI. A loopback-only smart HTTP Git fixture also serves the root YAML directly from its current Git branch. The test starts with an empty local mount, applies two methods, commits an expanded root that adds a third method and changes an existing workload, and verifies invalid root updates preserve the active configuration and workloads without container restart.

Validation: passed on disposable Fedora 44 EC2 with Podman 5.8.7 using the production image validated in #419 (the bootstrap/reload implementation is unchanged from main). The strict Sphinx build, shell syntax, Python compilation, and whitespace checks passed. Fixture and test resources are cleaned on exit; no test pushes to GitHub.

Addresses #417.

Summary by Sourcery

Document and continuously test Git-hosted root configuration for bootstrap and self-reconfiguration.

Enhancements:

• Document Git-hosted root configuration as a complete per-host bootstrap and self-reconfiguration workflow, including authentication, storage, trust, and resource-handling boundaries.

CI:

• Add a production-image integration test covering Git-hosted root bootstrap, scheduled root expansion, workload updates, and preservation of the active configuration after invalid root updates.

Documentation:

• Add comprehensive guidance for using Git-hosted root YAML configuration and distinguish it from recursive child-YAML imports.

Tests:

• Extend the Git fixture to serve the current root YAML over HTTP for integration testing.

[sourcery-ai]

Sorry @cooktheryan, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 3 days and 17 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

This PR documents the existing Git-hosted root self-configuration workflow and adds CI coverage using a production container, an isolated smart-HTTP Git fixture, scheduled root reloads, workload reconciliation, and preservation of the active configuration after invalid root updates; it introduces no runtime or schema changes.

Sequence diagram for Git-hosted root bootstrap and self-reconfiguration

sequenceDiagram
    participant Git as Git HTTP fixture
    participant FetchIt
    participant Mount as Local config mount
    participant Workloads

    FetchIt->>Git: HTTP GET root YAML via FETCHIT_CONFIG_URL
    Git-->>FetchIt: Root configuration from current branch
    FetchIt->>Mount: configReload
    FetchIt->>Workloads: Apply scheduled methods
    loop Recurring self-reconfiguration
        FetchIt->>Git: HTTP GET root YAML via FETCHIT_CONFIG_URL
        Git-->>FetchIt: Expanded root configuration
        FetchIt->>Mount: configReload
        FetchIt->>Workloads: Reconcile workload methods
    end
    alt Invalid root update
        Git-->>FetchIt: Invalid root YAML
        FetchIt-->>Mount: Preserve active configuration
        FetchIt-->>Workloads: Preserve active workloads
    end

Loading

File-Level Changes

Change	Details	Files
Document Git-hosted root configuration as a complete per-host bootstrap and self-reconfiguration workflow.	Add a per-host repository and root YAML walkthrough covering multiple workload repositories and scheduled methods. Explain bootstrap without local configuration, recurring config reloads, writable mounts, private-root authentication limitations, and root/workload trust boundaries. Distinguish root self-configuration from recursive child-YAML imports and Argo CD resource handling.	docs/index.rst docs/methods.rst docs/root_configuration.rst
Add production-image integration coverage for Git-hosted root bootstrap, reload, and invalid-update handling.	Run the root configuration test in the Docker image CI workflow. Start with an empty mount, bootstrap a root YAML over loopback HTTP, and verify two workload methods. Commit a root expansion and workload change, then verify the new method and updated workload without restarting the engine. Verify malformed downloaded root configuration is rejected while the active configuration and workloads remain intact.	.github/workflows/docker-image.yml tests/integration/root-config/test-root-config.sh
Extend the isolated Git fixture to serve the current root YAML directly from the repository branch.	Serve GET /config.yaml from refs/heads/main with YAML content and appropriate HTTP headers. Preserve the existing smart HTTP Git endpoints and return 404 when the branch file is unavailable.	tests/integration/live-update/git-server.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.