ArchyHCL

9 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
ssmithxandClaude Sonnet 5	dcc09ddee4	Automate deployment: push to main now deploys itself Deploy / deploy (push) Successful in 4s Details Registered a repo-scoped self-hosted runner (hcl-local-deploy) directly on the box serving hcl.archipelago-foundation.org, running in host (not docker) execution mode. Deploy is a plain local rsync — no SSH keys or remote credentials needed, since the runner already has filesystem access to the docroot. Runs as the debian user with no sudo; docroot ownership was changed from www-data to debian so this works without any privilege escalation (nginx only needs read access to serve it). ci.yml now runs on pull_request only — deploy.yml already validates before deploying on push to main, so running both on every push would just duplicate the check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 22:55:26 +00:00
ssmithxandClaude Sonnet 5	a22a9c9826	Initial scaffold: ArchyHCL, a community hardware compatibility list for Archipelago Build and validate / build (push) Successful in 1m38s Details Modeled on three researched precedents (see README): OpenWrt's Table of Hardware for the browsable sortable/filterable table UX, postmarketOS's working/community/testing tiers for the status field (collapsed to working/partial/broken here), and RaspiBlitz's scattered GitHub-issues approach as a negative example to avoid — hence structured YAML report files validated against a JSON Schema instead of free-text issue threads. - data/reports/*.yml + data/schema.json: one file per report, schema requires `issues` whenever status is partial/broken - scripts/build.py: validates every report and builds site/data.json, fails loudly on bad data (same idea as archy's own validate-app-manifest.sh) - site/: plain HTML/CSS/JS, no framework or build step, fetches data.json client-side — search, filter by status/form-factor, sortable columns, click a row for issues/notes detail - .github/ISSUE_TEMPLATE/hardware-report.yml: structured submission path for contributors who don't want to touch git directly - .gitea/workflows/ci.yml: runs the build/validate step on push and PRs Not yet deployed anywhere — see README's Deployment section. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-01 11:32:58 +00:00

Author

SHA1

Message

Date

ssmithxandClaude Sonnet 5

dcc09ddee4

Automate deployment: push to main now deploys itself

Deploy / deploy (push) Successful in 4s

Details

Registered a repo-scoped self-hosted runner (hcl-local-deploy) directly on
the box serving hcl.archipelago-foundation.org, running in host (not
docker) execution mode. Deploy is a plain local rsync — no SSH keys or
remote credentials needed, since the runner already has filesystem access
to the docroot. Runs as the debian user with no sudo; docroot ownership
was changed from www-data to debian so this works without any privilege
escalation (nginx only needs read access to serve it).

ci.yml now runs on pull_request only — deploy.yml already validates before
deploying on push to main, so running both on every push would just
duplicate the check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-03 22:55:26 +00:00

ssmithxandClaude Sonnet 5

a22a9c9826

Initial scaffold: ArchyHCL, a community hardware compatibility list for Archipelago

Build and validate / build (push) Successful in 1m38s

Details

Modeled on three researched precedents (see README): OpenWrt's Table of
Hardware for the browsable sortable/filterable table UX, postmarketOS's
working/community/testing tiers for the status field (collapsed to
working/partial/broken here), and RaspiBlitz's scattered GitHub-issues
approach as a negative example to avoid — hence structured YAML report
files validated against a JSON Schema instead of free-text issue threads.

- data/reports/*.yml + data/schema.json: one file per report, schema
  requires `issues` whenever status is partial/broken
- scripts/build.py: validates every report and builds site/data.json,
  fails loudly on bad data (same idea as archy's own
  validate-app-manifest.sh)
- site/: plain HTML/CSS/JS, no framework or build step, fetches data.json
  client-side — search, filter by status/form-factor, sortable columns,
  click a row for issues/notes detail
- .github/ISSUE_TEMPLATE/hardware-report.yml: structured submission path
  for contributors who don't want to touch git directly
- .gitea/workflows/ci.yml: runs the build/validate step on push and PRs

Not yet deployed anywhere — see README's Deployment section.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-01 11:32:58 +00:00