Repository navigation
fix(deploy): schedule the nightly backup only with an origin remote - #26
Merged
Merged
Conversation
A copy with no origin remote is a supported setup, but deploy installed the
nightly backup on every run. Its OPS stage then logged "'origin' does not
appear to be a git repository" each night and the session briefing showed
"Backup: ... did not finish clean" in every session.
deploy.sh and deploy.ps1 now schedule the cron entry or the OPS Daily Backup
task only when `git remote get-url origin` succeeds. With none they print one
line ("No git remote: the nightly backup is not scheduled. Add a GitHub remote
(DEPLOYMENT.md), then rerun deploy.") and carry on; it is not a failure. An
entry or task that already exists is never touched, and a warning names the fix
when there is no remote. daily-sync.sh is unchanged, so a copy with a remote
that cannot push still reports loudly.
The job also runs the nightly project pull and branch-gc, so a copy with no
remote runs those by hand; README and DEPLOYMENT.md say so. deploy.sh --help
prints its last two header lines again.
Tests: tests/deploy-cron-test.sh (new) and tests/deploy-windows-test.ps1 cover
origin present, no origin, a remote under another name, no repository, an
existing entry with and without an origin, and --no-system.
Exploitacious
added a commit
that referenced
this pull request
Nov 6, 2026
The 2026-11-05 change (#26) stopped deploy from scheduling the nightly job on a copy with no origin remote. That silenced the nightly "'origin' does not appear to be a git repository" error, but it also cost such a copy the job's nightly project pull and branch-gc --apply. daily-sync.sh is now the one place that decides what a copy with no origin does. It commits the day's work as always, then logs one line, "OPS: INFO no origin remote: the day's commit is kept locally; nothing pulled or pushed" (or "no local changes to commit" on a clean day), returns success, and the project and branch-gc stages run as on any copy. "No origin" is read from the local config (`git remote` lists no origin, matched in bash so pipefail cannot flip it), so an origin that exists but cannot be reached, or has only a push URL, is still a failed pull and an ERROR; a `git remote` that fails is an ERROR too. deploy.sh and deploy.ps1 schedule the job on every copy again and no longer look at the remotes. The session briefing reads the INFO line as "Backup: local only (no origin remote)", neither a failure nor quiet; an ERROR or WARN in the same run still wins. Kept from #26: its deploy test harnesses (now asserting the job is scheduled with and without an origin, and that the cron and task blocks run no git) and the deploy.sh --help fix. branch-gc-safety-test's daily-sync order case gets an origin in its fixture so it still exercises the pull. daily-sync-test.sh now names branch-gc (its fixture stub), so it starts with the sandbox guard. Docs: CHANGELOG, README ("The daily backup"), DEPLOYMENT.md (step 8, the Windows summary, the verification commands) and CONTEXT/how-i-work.md.
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
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.
What
deploy.shanddeploy.ps1now schedule the nightly backup (the user cron entry, theOPS Daily Backuptask) only when the OPS repo has anoriginremote.Why
A copy with no
originremote is a supported setup: OPS works without GitHub. Deploy still installed the nightly backup on every run. Its OPS stage then logged'origin' does not appear to be a git repositoryeach night, and the session briefing showedBackup: ... did not finish cleanin every session.Behavior
git init, a remote under another name such asupstream, or a directory that is not a repository): nothing is scheduled, and deploy printsNo git remote: the nightly backup is not scheduled. Add a GitHub remote (DEPLOYMENT.md), then rerun deploy.It is not a deploy failure.crontab -e, orUnregister-ScheduledTask).daily-sync.shis unchanged, so a copy that has a remote but cannot push still logs and reports loudly.deploy.sh --helpprinted all but the last two header lines after the header grew by a line; it prints them again.Worth a look
The nightly job also runs the project pull and
branch-gc --apply. A copy with no remote now has neither nightly. README and DEPLOYMENT.md say so and name the two commands to run by hand (branch cleanup also runs at pre-compaction and closeout). If you would rather keep those two stages scheduled, the alternative is to leave the schedule alone and havedaily-sync.shlog an informational line instead of an error when there is noorigin, skipping only its push stages. That changes the script's error behavior, which this PR deliberately does not.Tests
tests/deploy-cron-test.sh(new, sandboxed like the other deploy suites): slices the real cron block out ofdeploy.shand runs it against a fakecrontaband throwaway repos. Covers origin present (installed once, rerun adds nothing), no origin, another remote name, no repository, an existing entry with and without an origin (byte-identical, zero writes), unrelated entries surviving, and--no-system.tests/deploy-windows-test.ps1: the same rules for the scheduled task, with the ScheduledTask cmdlets replaced by recorders and the realgiton throwaway repos.deploy.sh/deploy.ps1.verify-ops.shafter a--no-systemdeploy (twice) in a throwawayHOME: 29 ok, 0 warn, 0 fail.CHANGELOG, README ("The daily backup"), DEPLOYMENT.md (step 8, the Windows summary and the verification commands) and CONTEXT/how-i-work.md are updated.