rob/PlaceMark
Watch
1
0
Fork
You've already forked PlaceMark
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Verify repository and CI process end to end #1

Merged
rob merged 2 commits from chore/verify-ci-process into main 2026-08-02 17:41:21 +00:00
Conversation 2 Commits 2 Files changed 2 +69
rob commented 2026-08-02 17:24:46 +00:00
Owner
Copy link

Process smoke test raised before any backlog work begins, to confirm the full loop is workable: push → PR → peer review → merge, plus whether Forgejo Actions has a runner.

Changes

  • CLAUDE.md — project guidance file, previously untracked locally.
  • .forgejo/workflows/verify-runner.yml — temporary, deliberately trivial workflow whose only job is to prove a runner picks up jobs. It is superseded by the real build/test/analyse pipeline in Vikunja task #5 and should be deleted when that lands.

What this is checking

  1. SSH push access to the remote.
  2. PR creation via the Forgejo MCP server.
  3. Peer review by an independent agent, per the workflow in CLAUDE.md.
  4. Merge via MCP.
  5. Whether a runner executes the workflow, or it queues forever.

Review outcomes actioned

  • The initial runs-on: ubuntu-latest matched no runner on this instance and left the job queued at waiting, which would have produced a false negative. Retargeted to ubuntu-24.04, matching the label other repositories on this instance use successfully.
  • Added workflow_dispatch so the probe can be re-triggered without a new commit.
  • Disambiguated the ticket reference as a Vikunja task rather than a Forgejo issue number.

No application code here — the solution scaffolding is Vikunja task #1 and follows once this loop is proven.

Process smoke test raised before any backlog work begins, to confirm the full loop is workable: push → PR → peer review → merge, plus whether Forgejo Actions has a runner. ## Changes - `CLAUDE.md` — project guidance file, previously untracked locally. - `.forgejo/workflows/verify-runner.yml` — **temporary**, deliberately trivial workflow whose only job is to prove a runner picks up jobs. It is superseded by the real build/test/analyse pipeline in Vikunja task #5 and should be deleted when that lands. ## What this is checking 1. SSH push access to the remote. 2. PR creation via the Forgejo MCP server. 3. Peer review by an independent agent, per the workflow in `CLAUDE.md`. 4. Merge via MCP. 5. Whether a runner executes the workflow, or it queues forever. ## Review outcomes actioned - The initial `runs-on: ubuntu-latest` matched no runner on this instance and left the job queued at `waiting`, which would have produced a false negative. Retargeted to `ubuntu-24.04`, matching the label other repositories on this instance use successfully. - Added `workflow_dispatch` so the probe can be re-triggered without a new commit. - Disambiguated the ticket reference as a Vikunja task rather than a Forgejo issue number. No application code here — the solution scaffolding is Vikunja task #1 and follows once this loop is proven.
Add CLAUDE.md and a temporary runner-verification workflow
Some checks failed
Verify runner / verify (pull_request) Has been cancelled
Details
9b8b66de56 
Seeds the repository with the project guidance file and a disposable
Forgejo Actions workflow used solely to confirm a runner is available
before the real CI pipeline is built.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rob reviewed 2026-08-02 17:28:34 +00:00
rob left a comment
Copy link

Independent review — verdict: CHANGES REQUESTED.

(Recorded as a comment review: Forgejo refuses REQUEST_CHANGES from the PR author's own account — "reject your own pull is not allowed" — and the reviewing agent shares that account. Treat the verdict below as the formal one.)

Judged as a bootstrap/process-verification change, not production CI — I have not asked for matrix builds, caching or test steps, which are rightly deferred to ticket #5.

The shape of this is good: .forgejo/workflows/ is the correct location for Forgejo Actions; the YAML is valid; the on: block is right, firing on every pull request and on pushes to main; the workflow avoids actions/checkout and any third-party action, so it tests only the runner itself, which is exactly what a runner probe should do. The comment at the top declaring the file temporary and naming its successor is a good touch. British spellings are used correctly throughout both files ("organised", "centralised", "authorisation", "analyse").

One blocking issue, and it goes to the whole point of the PR.

1. runs-on: ubuntu-latest almost certainly has no matching runner (.forgejo/workflows/verify-runner.yml, line 12) — blocking.

The run for this PR (run #87, event pull_request, SHA 9b8b66d) has been sitting in waiting with a start time of the Unix epoch for the several minutes since the PR was opened — it has never been dispatched to a runner. Meanwhile every other workflow on this instance that actually executes uses a different label:

  • Robware/api.auth → runs-on: ubuntu-24.04, latest run succeeded in 2m30s
  • Robware/api.blog → runs-on: ubuntu-24.04
  • rob/workflow_test → runs-on: ubuntu-24.04, ran for 2m21s before failing on its own script

So a runner does exist and does pick work up — it just does not advertise the ubuntu-latest label. Forgejo's runner, unlike GitHub's, only offers the labels it was registered with; ubuntu-latest is a GitHub-hosted convention rather than something Forgejo provides by default.

This matters more than a normal nit because the PR's stated purpose is to discover whether a runner exists. As it stands the job will queue indefinitely, and the observed result — nothing happens — is indistinguishable from "there is no runner at all". The experiment would return a false negative and the wrong conclusion would be recorded against the runner-verification ticket.

Please change line 12 to runs-on: ubuntu-24.04 to match the instance's established convention, and confirm the job actually starts before merging. Worth capturing the working label in CLAUDE.md too, so ticket #5 does not rediscover this.

2. Add workflow_dispatch to the triggers — optional but useful here.

For a probe whose whole job is to answer "does a runner pick this up?", being able to re-run it on demand without inventing a new commit is genuinely handy, especially if the runner turns out to be offline and is restarted later. One line under on:.

3. Minor: #5 in the workflow comment is ambiguous.

Line 2 refers to "ticket #5", meaning Vikunja task 5, but this repo has its own issue tracker enabled and Forgejo reads a bare #5 as a reference to issue 5 here. Suggest "Vikunja task 5" for clarity — the same applies to #5 and #1 in the PR description.

4. Minor: CLAUDE.md says the repository is empty.

"No code exists yet — the repository is empty" is accurate today but stops being true the moment this merges. Not worth holding the PR for; just something to correct when the scaffolding lands.

Nothing here is a security concern. The workflow runs no untrusted input, fetches no external actions, and touches no secrets, so the usual pull_request privilege worries do not apply. A permissions: block would be good practice for the real pipeline in ticket #5, but is not warranted for a two-line probe.

Fit to merge once the runs-on label is corrected and the run is observed to start.

Process note for the wider loop: because approval and rejection are both blocked on self-authored PRs, the "reviewer must approve before merge" step in CLAUDE.md cannot be satisfied through Forgejo's review state with a single account. Either create a second Forgejo account for the reviewing agent, or amend CLAUDE.md to accept a comment-review verdict as the gate.

**Independent review — verdict: CHANGES REQUESTED.** (Recorded as a comment review: Forgejo refuses `REQUEST_CHANGES` from the PR author's own account — "reject your own pull is not allowed" — and the reviewing agent shares that account. Treat the verdict below as the formal one.) Judged as a bootstrap/process-verification change, not production CI — I have not asked for matrix builds, caching or test steps, which are rightly deferred to ticket #5. The shape of this is good: `.forgejo/workflows/` is the correct location for Forgejo Actions; the YAML is valid; the `on:` block is right, firing on every pull request and on pushes to `main`; the workflow avoids `actions/checkout` and any third-party action, so it tests only the runner itself, which is exactly what a runner probe should do. The comment at the top declaring the file temporary and naming its successor is a good touch. British spellings are used correctly throughout both files ("organised", "centralised", "authorisation", "analyse"). One blocking issue, and it goes to the whole point of the PR. **1. `runs-on: ubuntu-latest` almost certainly has no matching runner (`.forgejo/workflows/verify-runner.yml`, line 12) — blocking.** The run for this PR (run #87, event `pull_request`, SHA `9b8b66d`) has been sitting in `waiting` with a start time of the Unix epoch for the several minutes since the PR was opened — it has never been dispatched to a runner. Meanwhile every other workflow on this instance that actually executes uses a different label: - `Robware/api.auth` → `runs-on: ubuntu-24.04`, latest run succeeded in 2m30s - `Robware/api.blog` → `runs-on: ubuntu-24.04` - `rob/workflow_test` → `runs-on: ubuntu-24.04`, ran for 2m21s before failing on its own script So a runner does exist and does pick work up — it just does not advertise the `ubuntu-latest` label. Forgejo's runner, unlike GitHub's, only offers the labels it was registered with; `ubuntu-latest` is a GitHub-hosted convention rather than something Forgejo provides by default. This matters more than a normal nit because the PR's stated purpose is to discover whether a runner exists. As it stands the job will queue indefinitely, and the observed result — nothing happens — is indistinguishable from "there is no runner at all". The experiment would return a false negative and the wrong conclusion would be recorded against the runner-verification ticket. Please change line 12 to `runs-on: ubuntu-24.04` to match the instance's established convention, and confirm the job actually starts before merging. Worth capturing the working label in `CLAUDE.md` too, so ticket #5 does not rediscover this. **2. Add `workflow_dispatch` to the triggers — optional but useful here.** For a probe whose whole job is to answer "does a runner pick this up?", being able to re-run it on demand without inventing a new commit is genuinely handy, especially if the runner turns out to be offline and is restarted later. One line under `on:`. **3. Minor: `#5` in the workflow comment is ambiguous.** Line 2 refers to "ticket #5", meaning Vikunja task 5, but this repo has its own issue tracker enabled and Forgejo reads a bare `#5` as a reference to issue 5 here. Suggest "Vikunja task 5" for clarity — the same applies to `#5` and `#1` in the PR description. **4. Minor: `CLAUDE.md` says the repository is empty.** "**No code exists yet** — the repository is empty" is accurate today but stops being true the moment this merges. Not worth holding the PR for; just something to correct when the scaffolding lands. Nothing here is a security concern. The workflow runs no untrusted input, fetches no external actions, and touches no secrets, so the usual `pull_request` privilege worries do not apply. A `permissions:` block would be good practice for the real pipeline in ticket #5, but is not warranted for a two-line probe. Fit to merge once the `runs-on` label is corrected and the run is observed to start. **Process note for the wider loop:** because approval and rejection are both blocked on self-authored PRs, the "reviewer must approve before merge" step in `CLAUDE.md` cannot be satisfied through Forgejo's review state with a single account. Either create a second Forgejo account for the reviewing agent, or amend `CLAUDE.md` to accept a comment-review verdict as the gate.
.forgejo/workflows/verify-runner.yml Outdated
@ -0,0 +9,4 @@
jobs:
verify:
runs-on: ubuntu-latest
rob commented 2026-08-02 17:28:34 +00:00
Author
Owner
Copy link

ubuntu-latest is a GitHub-hosted convention; Forgejo runners only offer the labels they were registered with. Every workflow on this instance that actually executes uses ubuntu-24.04 (Robware/api.auth, Robware/api.blog, rob/workflow_test), and this PR's run is stuck in waiting, never dispatched. Change to ubuntu-24.04, otherwise this probe returns a false negative.

`ubuntu-latest` is a GitHub-hosted convention; Forgejo runners only offer the labels they were registered with. Every workflow on this instance that actually executes uses `ubuntu-24.04` (`Robware/api.auth`, `Robware/api.blog`, `rob/workflow_test`), and this PR's run is stuck in `waiting`, never dispatched. Change to `ubuntu-24.04`, otherwise this probe returns a false negative.
rob force-pushed chore/verify-ci-process from 9b8b66de56
Some checks failed
Verify runner / verify (pull_request) Has been cancelled
Details
to 36f6277c4e
All checks were successful
Verify runner / verify (pull_request) Successful in 21s
Details
2026-08-02 17:34:18 +00:00 Compare
rob reviewed 2026-08-02 17:40:48 +00:00
rob left a comment
Copy link

Re-review of 36f6277 — verdict: APPROVED-equivalent. Fit to merge.

(Recorded as a comment review because Forgejo blocks both APPROVED and REQUEST_CHANGES on a self-authored PR. Treat this as the formal approval for the purposes of the CLAUDE.md review gate.)

Everything raised in the first pass has been addressed, and the blocking issue is confirmed resolved by evidence rather than inspection alone:

  • runs-on: ubuntu-24.04 (.forgejo/workflows/verify-runner.yml, line 13) — run #88 on 36f6277 completed success in 22s, against run #87 on ubuntu-latest which never left waiting and is now cancelled. That is a clean before/after and it answers the question the PR set out to ask: this instance has a working Actions runner, and its label is ubuntu-24.04. Please record that label somewhere durable so Vikunja task #5 does not have to rediscover it.
  • workflow_dispatch added to the on: block — the probe can now be re-triggered without a new commit.
  • Ticket reference disambiguated to "Vikunja task #5" in both the workflow header and the PR body.

I also checked the two things that the force-push touched but that were not part of my review: CLAUDE.md is byte-identical to what I reviewed (blob b893092 unchanged), and both commit messages on the branch are now free of attribution trailers. The rewritten commit message on 36f6277 explains the runner-label change and its rationale properly — good practice for a change whose reasoning is not obvious from the diff.

On my point 4, which was not actioned: I accept the pushback and withdraw it. "No code exists yet" is the operative claim and it stays true until scaffolding lands; correcting it as part of Vikunja task #1 is the right sequencing. It was a nit and I flagged it as such.

One trivial observation, not blocking and not worth another round trip: Forgejo will still auto-link the bare #5 in the PR body to issue 5 in this repository if one is ever created, since the "Vikunja task" prefix disambiguates for a human reader but not for the renderer. Inside the YAML comment it does not render at all, so that instance is entirely fine. Worth bearing in mind as a general habit once this repo's own issue tracker sees use.

Nothing further from me. Merge when ready, and remember this workflow is due for deletion when the real pipeline lands in Vikunja task #5.

**Re-review of `36f6277` — verdict: APPROVED-equivalent. Fit to merge.** (Recorded as a comment review because Forgejo blocks both `APPROVED` and `REQUEST_CHANGES` on a self-authored PR. Treat this as the formal approval for the purposes of the `CLAUDE.md` review gate.) Everything raised in the first pass has been addressed, and the blocking issue is confirmed resolved by evidence rather than inspection alone: - **`runs-on: ubuntu-24.04`** (`.forgejo/workflows/verify-runner.yml`, line 13) — run #88 on `36f6277` completed **success in 22s**, against run #87 on `ubuntu-latest` which never left `waiting` and is now cancelled. That is a clean before/after and it answers the question the PR set out to ask: this instance has a working Actions runner, and its label is `ubuntu-24.04`. Please record that label somewhere durable so Vikunja task #5 does not have to rediscover it. - **`workflow_dispatch` added** to the `on:` block — the probe can now be re-triggered without a new commit. - **Ticket reference disambiguated** to "Vikunja task #5" in both the workflow header and the PR body. I also checked the two things that the force-push touched but that were not part of my review: `CLAUDE.md` is byte-identical to what I reviewed (blob `b893092` unchanged), and both commit messages on the branch are now free of attribution trailers. The rewritten commit message on `36f6277` explains the runner-label change and its rationale properly — good practice for a change whose reasoning is not obvious from the diff. **On my point 4, which was not actioned: I accept the pushback and withdraw it.** "No code exists yet" is the operative claim and it stays true until scaffolding lands; correcting it as part of Vikunja task #1 is the right sequencing. It was a nit and I flagged it as such. One trivial observation, not blocking and not worth another round trip: Forgejo will still auto-link the bare `#5` in the PR body to issue 5 in this repository if one is ever created, since the "Vikunja task" prefix disambiguates for a human reader but not for the renderer. Inside the YAML comment it does not render at all, so that instance is entirely fine. Worth bearing in mind as a general habit once this repo's own issue tracker sees use. Nothing further from me. Merge when ready, and remember this workflow is due for deletion when the real pipeline lands in Vikunja task #5.
rob merged commit 9e33087cc6 into main 2026-08-02 17:41:21 +00:00
rob deleted branch chore/verify-ci-process 2026-08-02 17:41:22 +00:00
rob referenced this pull request from a commit 2026-08-02 18:09:48 +00:00
Scaffold the solution structure
rob referenced this pull request from a commit 2026-08-02 18:50:09 +00:00
Scaffold the solution structure (#3)
rob referenced this pull request from a commit 2026-08-02 19:11:00 +00:00
Convert the solution to the .slnx format
rob referenced this pull request from a commit 2026-08-03 07:20:02 +00:00
Document the v1 data model (#11)
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rob/PlaceMark!1
No description provided.