fleet-health.json now publishes the collection version each scope last applied (the deployed object: platform and one entry per node), but nothing compares it with the version the fleet repository pins, so a scope left behind is visible only to someone who reads the gist. arc.yml alone, for example, leaves every node on the previous release.
The pin lives in ExaDev/github-runner-fleet requirements.yml and the stamps live in the cluster, so the comparison belongs in the fleet repository (a scheduled workflow that reads the gist's fleet-health.json and fails or opens an issue when any entry differs from the pin), not in the heartbeat, which does not know the pin. Agent hosts cannot stamp, so the check has to tolerate a null for a node whose role is agent.
Follow-up to #49. Deferred because the fleet repository has no workflow today and the gist is secret, so a CI job would need read access to it (a credential, the owner's call).
fleet-health.jsonnow publishes the collection version each scope last applied (thedeployedobject:platformand one entry per node), but nothing compares it with the version the fleet repository pins, so a scope left behind is visible only to someone who reads the gist.arc.ymlalone, for example, leaves every node on the previous release.The pin lives in
ExaDev/github-runner-fleetrequirements.ymland the stamps live in the cluster, so the comparison belongs in the fleet repository (a scheduled workflow that reads the gist'sfleet-health.jsonand fails or opens an issue when any entry differs from the pin), not in the heartbeat, which does not know the pin. Agent hosts cannot stamp, so the check has to tolerate anullfor a node whose role is agent.Follow-up to #49. Deferred because the fleet repository has no workflow today and the gist is secret, so a CI job would need read access to it (a credential, the owner's call).