Skip to content

Review pull requests and work labelled issues without a person - #45

Open
w4ffl35 wants to merge 3 commits into
mainfrom
automation/pipeline
Open

w4ffl35 wants to merge 3 commits into
mainfrom
automation/pipeline

Conversation

@w4ffl35

@w4ffl35 w4ffl35 commented Sep 16, 2026

Copy link
Copy Markdown
Member

Matches what spikeforge-dashboard now has, so a ticket in either place
starts the same way.

  • One workflow turns an agent-labelled issue into a pull request.
  • The other reviews every pull request.

Neither may merge. Required checks decide that, which is the only reason
letting a model write code here is reasonable.

Both prompts point at this repository's own rules and at the two failures
that hurt most from here: a version change that leaves compatibility.json
behind — which ships a mismatched engine to the dashboard and the desktop
application — and a protocol or published-surface change that nothing
downstream was updated for.

Dependabot is grouped per ecosystem, with torch on its own because it decides
what the engine can run and how large every artifact is.

Secrets this needs

  • ANTHROPIC_API_KEY — both workflows. The review workflow skips itself
    without it rather than failing every pull request.
  • AUTOMATION_TOKEN — the issue workflow. A pull request opened with the
    built-in token never gets checks, so it could never auto-merge.

What was run

The workflow files parse. Neither has run: both need secrets that are not set
on this repository yet.

Matches what the dashboard repository now has, so a ticket in either
place starts the same way.

One workflow turns an `agent`-labelled issue into a pull request; the
other reviews every pull request. Neither may merge -- required checks
decide that, which is the only reason letting a model write code here is
reasonable. Both prompts point at this repository's own rules and at the
two failures that hurt most from here: a version change that leaves
compatibility.json behind, which ships a mismatched engine to the
dashboard and the desktop application, and a protocol or
published-surface change nothing downstream was updated for.

Dependabot is grouped per ecosystem, with torch on its own because it
decides what the engine can run and how large every artifact is.

The workflow files parse. Neither has run: both need secrets that are
not set on this repository yet.
Every job here sets up Python with `cache: pip`, and on this fleet that
step fails outright: "No file ... matched to [**/requirements.txt or
**/pyproject.toml], make sure you have checked out the target
repository". All seven pyproject.toml files are present in `packages/`
at that exact path -- checked on the runner's own workspace while a job
sat failed.

The runners keep `_work` on another drive behind a symlink, and the
action's dependency-file glob does not see through it. It has taken out
`blocked-deps`, `client`, `docs` and all five `extras` jobs, and it took
out the dashboard's release workflow earlier today for the same reason.
It is not reliably reproducible -- an earlier run on main globbed fine --
which makes it worse, not better: a pipeline that merges on green will
see spurious red it cannot distinguish from a real failure.

Removing it costs nothing. A self-hosted runner keeps `~/.cache/pip`
between jobs by itself, so the action was caching a cache.
The two workflows called anthropics/claude-code-action and wanted an
ANTHROPIC_API_KEY. This repository is not going to have one, so both now
speak plain chat-completions: the review posts through
scripts/llm_review.mjs, and the issue worker drives aider with
OPENAI_API_BASE pointed wherever LLM_BASE_URL says. OpenRouter and
DeepInfra both serve that protocol, so the provider is two variables.

LLM_MODEL has no default on purpose. A guessed slug fails at the
provider with an opaque error on somebody else's pull request, which is
worse than refusing to start.

The issue body reaches the agent through a file rather than a shell
argument. It is arbitrary text from whoever opened the issue, and
interpolating it into a command would let its contents decide what runs.

Also raises the subprocess timeout in test_rebuild_is_bit_exact_in_a_
subprocess from 180s to 600s. It timed out today on a runner sharing
this workstation with two other jobs, and reported it as a
bit-exactness failure that had not happened -- red that looks exactly
like the defect the test is named after.

Run here: the 9 llm_review tests, and both workflow files parse. The
workflows themselves have not run; they need secrets that are not set.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant