Skip to content

feat: taskless demo runtime, and clear the openspec backlog #9

feat: taskless demo runtime, and clear the openspec backlog

feat: taskless demo runtime, and clear the openspec backlog #9

Workflow file for this run

# Runs the shipped demonstration rule's own fixtures.
#
# ## Why this is its own workflow
#
# It is the one job here that deliberately executes a rule's `check.ts`. That
# is arbitrary code by design — the runtime tier exists to run it — and a job
# with that power should be readable as its own thing rather than buried as a
# step inside a general one.
#
# ## Two honest caveats, so nobody reads more into this than it does
#
# **It does not block a merge.** Branch protection requires `Validate` and
# nothing else, so a failure here is visible and advisory until someone adds
# this check to the protection rule. That is the same reason the house-style
# scan lives inside `validate.yml` rather than beside it.
#
# **It is not the only place `check.ts` runs in CI.** `test/demo-runtime.test.ts`
# executes it too, under `Validate`. What this job adds is a different
# assertion: it copies `assets/demo-runtime/` into a bare project AS-IS and runs
# the engines over it, with no command and no bundle in the way. So a break in
# the shipped asset tree is attributed to the asset tree, rather than to the
# command that writes it or the imports that embed it.
name: Demo rule
on:
push:
branches: [main]
# No `branches:` filter, and `ready_for_review` named explicitly. See the long
# note in `validate.yml`: a filtered workflow silently stopped running on
# stacked PRs past a certain depth, and `ready_for_review` is not in the
# default event set.
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
permissions:
contents: read
jobs:
demo-rule:
name: Demo rule
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Install pnpm
uses: pnpm/action-setup@v6
- name: Setup Node
uses: actions/setup-node@v6
with:
node-version: 24
- name: Install dependencies
run: pnpm install --frozen-lockfile
- name: Build
run: pnpm build
# A bare project, not this repository. The rule flags undeclared
# `process.env` reads, and running it over a checkout of the CLI would
# report the CLI's own reads — a scan of the wrong tree that happens to
# produce output.
- name: Stage the shipped rule in a bare project
run: |
set -euo pipefail
PROJECT="$(mktemp -d)"
echo "PROJECT=$PROJECT" >> "$GITHUB_ENV"
git -C "$PROJECT" init -q
node packages/cli/dist/index.js init -d "$PROJECT"
RULE="$PROJECT/.taskless/rules/runtime/env-keys-declared"
mkdir -p "$RULE"
cp -R packages/cli/assets/demo-runtime/. "$RULE/"
- name: Verify
run: node packages/cli/dist/index.js verify -d "$PROJECT"
# `--dangerously-run-scripts` is the whole point of this job: without it
# the fixtures do not run, and `test` says so rather than reporting a
# pass. A green run here means they executed.
- name: Run the rule's fixtures
run: |
set -euo pipefail
node packages/cli/dist/index.js test --json --dangerously-run-scripts -d "$PROJECT" | tee /tmp/report.json
node -e '
const report = JSON.parse(require("fs").readFileSync("/tmp/report.json", "utf8"));
const rule = report.rules.find((r) => r.ruleId === "env-keys-declared");
if (!rule) throw new Error("no report for env-keys-declared");
if (rule.ran !== true) throw new Error("fixtures did not run: " + JSON.stringify(rule));
if (rule.ok !== true) throw new Error("fixtures failed: " + JSON.stringify(rule.errors));
'