Severity: low · Type: performance · Confidence: high
Location:.gitea/workflows/ci.yml:16-20 (trigger block: push: branches: [lotus], push: tags: ['v*'], pull_request: branches: [lotus]) — no concurrency: key anywhere in the file
Problem
LOTUS_TODO.md documents that cinny's own ci.yml was hardened with concurrency: cancel-in-progress specifically because a burst of pushes to lotus-equivalent branches piles up ~30-minute builds on a shared Gitea runner. This element-call ci.yml (explicitly modeled on cinny's) was not given the same treatment: a rapid sequence of pushes to lotus (e.g. during an audit-fix batch, several of which are visible in git log) queues one full build job (Node 24, NODE_OPTIONS=--max-old-space-size=16384) per push instead of collapsing to the latest.
How to trigger
Push several commits to lotus in quick succession; each triggers its own full build job run to completion instead of being cancelled by the newer push.
Suggested fix
Add a concurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true } block at the workflow level, mirroring the cinny fix.
Filed from the September 2026 audit (branch lotus).
**Severity:** low · **Type:** performance · **Confidence:** high
**Location:** `.gitea/workflows/ci.yml:16-20` (trigger block: `push: branches: [lotus]`, `push: tags: ['v*']`, `pull_request: branches: [lotus]`) — no `concurrency:` key anywhere in the file
### Problem
LOTUS_TODO.md documents that cinny's own `ci.yml` was hardened with `concurrency: cancel-in-progress` specifically because a burst of pushes to `lotus`-equivalent branches piles up ~30-minute builds on a shared Gitea runner. This element-call `ci.yml` (explicitly modeled on cinny's) was not given the same treatment: a rapid sequence of pushes to `lotus` (e.g. during an audit-fix batch, several of which are visible in `git log`) queues one full `build` job (Node 24, `NODE_OPTIONS=--max-old-space-size=16384`) per push instead of collapsing to the latest.
### How to trigger
Push several commits to `lotus` in quick succession; each triggers its own full `build` job run to completion instead of being cancelled by the newer push.
### Suggested fix
Add a `concurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true }` block at the workflow level, mirroring the cinny fix.
---
_Filed from the September 2026 audit (branch `lotus`)._
jared
added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:15 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: low · Type: performance · Confidence: high
Location:
.gitea/workflows/ci.yml:16-20(trigger block:push: branches: [lotus],push: tags: ['v*'],pull_request: branches: [lotus]) — noconcurrency:key anywhere in the fileProblem
LOTUS_TODO.md documents that cinny's own
ci.ymlwas hardened withconcurrency: cancel-in-progressspecifically because a burst of pushes tolotus-equivalent branches piles up ~30-minute builds on a shared Gitea runner. This element-callci.yml(explicitly modeled on cinny's) was not given the same treatment: a rapid sequence of pushes tolotus(e.g. during an audit-fix batch, several of which are visible ingit log) queues one fullbuildjob (Node 24,NODE_OPTIONS=--max-old-space-size=16384) per push instead of collapsing to the latest.How to trigger
Push several commits to
lotusin quick succession; each triggers its own fullbuildjob run to completion instead of being cancelled by the newer push.Suggested fix
Add a
concurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true }block at the workflow level, mirroring the cinny fix.Filed from the September 2026 audit (branch
lotus).Fixed in
9c521463, shipped in0.25.0-lotus.1(published by CI from tag v0.25.0-lotus.1) and consumed by cinny at 9a85a487.