Repository navigation
chore(ci): run the Azure signer oracle in CI - #50
Merged
Merged
Conversation
The SharedKey/SAS oracle (test/azure-oracle.node.ts) was only reachable via `pnpm test:azure-oracle`, which no workflow invoked, so a PR that broke Azure signature compatibility merged green. CI's Test job runs `pnpm test:ci:coverage`, so chain the oracle into both CI test scripts. It is a separate Node process (tsx) with no network and no credentials, runs before vitest and aborts the script when it fails. Refs #48
Contributor
Author
Coverage
|
Alex1990
added a commit
that referenced
this pull request
Sep 15, 2026
…fault The first real loop PR (#50) showed the approval-required state is per *run*, not per PR: `CI` and `Loop` both sat at `completed/action_required`, and approving just the first ran CI to green while leaving `Loop` untouched — that is, the loop verified its own change without reviewing its own work. The UI button approves both, so the text now names the API path (`POST /actions/runs/<id>/approve`) and says which to pick when.
Alex1990
added a commit
that referenced
this pull request
Sep 15, 2026
… two The first real `pr-opened` run (task #48, PR #50) logged `GitHub actions executed: 2` while having executed four: `applyActions` ran the push and the PR creation in `finishRun`'s pre-flight, and only the label and comment were left in `actions` — the list the log line and the Step Summary count from. The two writes that matter most were the two the report did not mention, so the summary of a run that opened a PR read as if it had only tagged an issue. `finishRun` now keeps what the pre-flight executed and prepends it to the plan for the rest, so `actions` and `applied` describe the whole run in the order it happened (push → pr-create → label → comment). The report-boundary path is unaffected: `validatePush` refuses `pr-opened` there, so the pre-flight never runs and nothing is prepended.
Alex1990
added a commit
that referenced
this pull request
Sep 15, 2026
…fault The first real loop PR (#50) showed the approval-required state is per *run*, not per PR: `CI` and `Loop` both sat at `completed/action_required`, and approving just the first ran CI to green while leaving `Loop` untouched — that is, the loop verified its own change without reviewing its own work. The UI button approves both, so the text now names the API path (`POST /actions/runs/<id>/approve`) and says which to pick when.
This was referenced Sep 17, 2026
Alex1990
pushed a commit
that referenced
this pull request
Sep 17, 2026
agentEnv() injected 'tiny-oss loop <loop@users.noreply.github.com>' as the git identity under auto. That address belongs to the real, unrelated GitHub user @loop (id 1519971), so every loop commit - 8ec1b1e (PR #50) and 4d2735a/35c7312 (PR #55) - was falsely attributed to a stranger (#52, #56). Use GitHub Actions' own bot instead, the same identity the host's PR is authored by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>. A bot noreply address is not a user account, so it cannot be squatted. Only future commits change; the historical ones stay as they are.
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
2 participants
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.
Closes #48
loop-task: #48
Why
The Azure SharedKey/SAS oracle (
test/azure-oracle.node.ts) was reachable only throughpnpm test:azure-oracle, and no workflow invoked it (.github/workflows/ci.ymlrunspnpm lintandpnpm test:ci:coverage, a vitest browser run). A PR that broke Azure signature compatibility therefore merged green, while the AWS/COS/OBS oracles are pinned by vitest specs CI already runs.What
Chain the existing oracle script into both CI test entry points in
package.json:test:ci:pnpm test:azure-oracle && vitest run --browser.headlesstest:ci:coverage:pnpm test:azure-oracle && vitest run --browser.headless --coverageCI's Test job runs
pnpm test:ci:coverage, so the oracle now executes before vitest and its non-zero exit fails the step. Chaining intotest:citoo keeps the two entry points consistent. The oracle itself (fixed 32-byte key, pinnedFixedDateclock, mocked request, no network/credentials) and every signer are unchanged, and no workflow file is touched — the job token cannot push.github/workflows/**anyway.Verification
pnpm test:ci:coverage(exact CI command): exit 0, oracle output present,Test Files 22 passed (22), 231 passed / 26 skipped.pnpm exec tsx … && echo CHAIN_CONTINUEDexit 1 with no continuation (copy deleted; real oracle untouched).pnpm lint,pnpm fmt:check,pnpm check:types,pnpm buildall exit 0.chore(ci): repository/CI tooling with no consumer-observable behaviour, per AGENTS.md.