Moving htmlproof and build validations to GitHub actions

.github/copilot-instructions.md

@@ -20,4 +20,4 @@ If this file conflicts with `AGENTS.md`, prefer `AGENTS.md`.
 
 When the local environment supports it, use the build and validation commands documented in `AGENTS.md`.
 
-GitHub Pages production is configured to deploy from `main`. CircleCI handles build/htmlproofer validation. GitHub Actions handles the version/tag release flow. Do not change CI, deployment, or versioning without maintainer approval.
+GitHub Pages production is configured to deploy from `main`. GitHub Actions handles conference data validation, the Jekyll build, htmlproofer, and the version/tag release flow. Do not change CI, deployment, or versioning without maintainer approval.

.github/workflows/ci.yml

@@ -0,0 +1,32 @@
+name: CI
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '3.2'
+          bundler-cache: true
+
+      - name: Validate conference data
+        run: ruby tools/validate_data.rb
+
+      - name: Build with Jekyll
+        run: bundle exec jekyll build --verbose
+
+      - name: Validate generated site
+        run: bundle exec htmlproofer ./_site --disable-external --no-enforce-https --allow-missing-href --ignore-urls '/^\/\//'

AGENTS.md

@@ -17,18 +17,18 @@ TestingConferences.org is a community-maintained Jekyll site for software testin
 
 ## CI And Deployment
 
-This repository currently uses GitHub Pages, GitHub Actions, and CircleCI.
+This repository uses GitHub Pages and GitHub Actions.
 
 - GitHub Pages production is configured to deploy from the `main` branch.
-- GitHub Actions is used for the site release flow that appends/increments the site version number and creates tags.
-- CircleCI is responsible for build and htmlproofer validation.
+- GitHub Actions validates pull requests and pushes to `main` by running the conference data validator, Jekyll build, and htmlproofer.
+- GitHub Actions also runs the site release flow that appends/increments the site version number and creates tags.
 - `.github/workflows/deploy.yml` currently includes Pages artifact upload/deploy steps even though repository settings deploy Pages from `main`; treat changes to this workflow as deployment/versioning work that needs maintainer approval.
 
 Relevant files:
 
 - `.github/workflows/deploy.yml`
+- `.github/workflows/ci.yml`
 - `.github/workflows/auto-assign.yml`
-- `.circleci/config.yml`
 
 ## Safe Edit Zones
 

Agent_Readiness.md

@@ -10,30 +10,28 @@ The main remaining weakness is that most guardrails are still documented in pros
 
 **AI-assisted edits:** 8/10
 
-**Autonomous agent workflows:** 6/10
+**Autonomous agent workflows:** 7/10
 
-The project has a simple Jekyll structure, clear conference data files, a root agent instruction file, a conference data validator, documented CI/deploy ownership, and useful contributor documentation. Autonomous workflows still need CI integration for the validator and better documentation for maintenance scripts.
+The project has a simple Jekyll structure, clear conference data files, a root agent instruction file, a conference data validator enforced in CI, documented CI/deploy ownership, and useful contributor documentation. Autonomous workflows still need better documentation for maintenance scripts and clearer formatting automation.
 
 ## What Already Helps Agents
 
 - `AGENTS.md` is now the strongest agent-facing file. It explains the project map, safe edit zones, conference data rules, source-of-truth policy, local commands, validation checklist, common tasks, and changes that need maintainer approval.
 - `README.md` explains the project, `_data` files, ordering rules, required conference fields, eligibility, and deployment versioning.
-- `README.md` now documents the current deployment split: GitHub Pages deploys from `main`, GitHub Actions handles the version/tag release flow, and CircleCI handles build/htmlproofer validation.
+- `README.md` now documents the current deployment model: GitHub Pages deploys from `main`, while GitHub Actions handles conference data validation, the Jekyll build, htmlproofer, and the version/tag release flow.
 - `CONTRIBUTING.md` gives contributor workflows for adding conferences, reporting issues, and page/navigation changes.
 - `SETUP.md` provides Docker setup instructions.
 - `.github/copilot-instructions.md` now delegates repo-wide policy to `AGENTS.md` and keeps only Copilot-specific reminders.
 - `.github/pull_request_template.md` provides a checklist for conference PRs.
 - `CODEOWNERS` assigns review ownership.
 - `Gemfile`, `docker-compose.yml`, and `devops/setup.sh` make it clear this is a Ruby/Jekyll/GitHub Pages site.
 - `tools/validate_data.rb` provides a machine-checkable conference data validator for the YAML data files.
-- `.circleci/config.yml` documents the build and htmlproofer validation commands used by CircleCI.
+- `.github/workflows/ci.yml` validates pull requests and pushes to `main` with the conference data validator, Jekyll build, and htmlproofer.
 - `ROADMAP.md` now tracks the remaining agent-readiness work, quality metrics work, validation work, and developer-experience improvements.
 - `tools/` contains maintenance scripts, especially `tools/identify_updates.rb`, though these scripts are not yet documented.
 
 ## Main Gaps
 
-- The conference data validator exists, but it is not yet wired into CI.
-- There is no obvious pull request validation workflow owned by GitHub Actions. CircleCI performs build validation, but the validator is not yet part of that validation.
 - The CI/deploy story still has one confusing implementation detail: `.github/workflows/deploy.yml` includes Pages artifact upload/deploy steps even though repository settings deploy Pages from the `main` branch.
 - Formatting guidance is partial. The repo has `.prettierrc`, but there is no `package.json`, documented Prettier command, ESLint config, `.editorconfig`, or Ruby lint config.
 - Issue templates now exist with site-version fields, but there is not yet any automation that aggregates issues by version.
@@ -47,19 +45,13 @@ The project has a simple Jekyll structure, clear conference data files, a root a
 1. Simplify or rename `.github/workflows/deploy.yml` so the workflow implementation matches the confirmed deployment model.
    - Keep the version increment and tag behavior if still wanted.
    - Remove or explain the Pages artifact/deploy steps if production deploys from `main`.
-2. Add the conference data validator to PR validation.
-   - `ruby tools/validate_data.rb`.
-3. Add or document PR validation expectations.
-   - CircleCI build.
-   - Jekyll build.
-   - htmlproofer.
-4. Document the `tools/` scripts or remove/replace the ones that are no longer part of the workflow.
-5. Add documented formatting commands for Prettier, and either add ESLint intentionally or stop referring to ESLint as expected tooling.
-6. Add automation or reporting that connects issue-template site-version data to the quality ledger.
-7. Make local verification docs clearer for both Docker and non-Docker setups.
+2. Document the `tools/` scripts or remove/replace the ones that are no longer part of the workflow.
+3. Add documented formatting commands for Prettier, and either add ESLint intentionally or stop referring to ESLint as expected tooling.
+4. Add automation or reporting that connects issue-template site-version data to the quality ledger.
+5. Make local verification docs clearer for both Docker and non-Docker setups.
 
 ## Current Bottom Line
 
 The repo is now ready for supervised AI agents to make narrow, reviewable changes such as adding, updating, moving, or closing conference entries.
 
-It is not yet ready for broad autonomous maintenance because the most important rules are still human-readable instructions rather than executable checks.
+It is not yet ready for broad autonomous maintenance because several maintenance workflows and formatting expectations remain human-readable guidance rather than executable checks.

README.md

@@ -1,4 +1,4 @@
-# [Testing Conferences](https://testingconferences.org) [![CircleCI](https://circleci.com/gh/TestingConferences/testingconferences.github.io.svg?style=svg)](https://circleci.com/gh/TestingConferences/testingconferences.github.io) [![License: MIT](https://img.shields.io/badge/License-MIT-brightgreen.svg)](https://opensource.org/licenses/MIT) 
+# [Testing Conferences](https://testingconferences.org) [![CI](https://github.com/TestingConferences/testingconferences.github.io/actions/workflows/ci.yml/badge.svg)](https://github.com/TestingConferences/testingconferences.github.io/actions/workflows/ci.yml) [![License: MIT](https://img.shields.io/badge/License-MIT-brightgreen.svg)](https://opensource.org/licenses/MIT)
 
 > [!IMPORTANT]
 > We've switch TO `main` and away from `master` branch
@@ -81,8 +81,7 @@ The site uses an automated versioning system to track each deployment:
 - **Git Tags**: Each deployment is tagged in Git with the format `vXXXX` (e.g., `v1501`)
 - **Footer Display**: The current version is displayed in the site footer as `rev.XXXX.`
 - **GitHub Pages**: Production is configured to deploy from the `main` branch.
-- **GitHub Actions**: Used for the site release flow that appends/increments the version number and creates tags.
-- **CircleCI**: Handles build and htmlproofer validation.
+- **GitHub Actions**: Validates conference data, builds the site, runs htmlproofer, and manages the version/tag release flow.
 
 This versioning system enables:
 - Tracking which version of the site is deployed

ROADMAP.md

@@ -17,7 +17,7 @@ Continue to use TCorg to experiment and learn. I want to track quality metrics a
 - [ ] **Build Analytics**: Track and log build times to monitor the impact of site growth on CI/CD performance.
 - [x] **Bug Attribution**: Update Issue Templates to include a "Site Version" field to track bug counts relative to specific releases.
 - [x] **Conference Data Validator**: Add a machine-checkable validator for `_data/current.yml`, `_data/past.yml`, and `_data/closed.yml` covering required fields, allowed fields, duplicate names, chronological ordering, URL tracking parameters, and `twitter` formatting.
-- [ ] **PR Validation**: Add a pull request workflow that runs the Jekyll build and conference data validator before merge.
+- [x] **PR Validation**: Add a pull request workflow that runs the conference data validator, Jekyll build, and htmlproofer before merge.
 
 ## Phase 3: Developer Experience (DX) & AI Workflows
 *Goal: Streamline contributions using automation and AI context.*