ci: add GitHub Actions deploy workflow for GitHub Pages

[mmcky]

Summary

Switches production publishing from the legacy "Deploy from a branch" method (which pins to the GitHub Pages gem sandbox / Jekyll 3.10) to a proper GitHub Actions workflow so the Gemfile's Jekyll 4.4 is used in production.

What changed

Added .github/workflows/deploy.yml using the standard GitHub Pages Actions pattern:

1. ruby/setup-ruby — same Ruby 3.2 + bundler-cache: true config as the existing build.yml
2. actions/configure-pages — emits the correct base_path for the site URL
3. bundle exec jekyll build with JEKYLL_ENV=production
4. actions/upload-pages-artifact → actions/deploy-pages

Triggers on push to main and workflow_dispatch. The deploy job is guarded by if: github.ref == 'refs/heads/main' and deployment credentials (pages: write, id-token: write) are scoped to the deploy job only. The existing build.yml (PR preview) is left untouched.

Pre-merge review fixes

• _config.yml: added url: "https://quantecon.org". The legacy Pages builder injects site.url automatically (the live site's og:url is absolute today); a plain jekyll build in Actions does not, which would have silently broken og:url meta tags and post share links after the switch.
• sitemap.xml: emit absolute <loc> URLs via absolute_url as the sitemap spec requires. The live sitemap is currently relative — a pre-existing bug this fixes as a side benefit.
• actions/checkout bumped to v6 to match build.yml on main.

Required manual step after merge

Settings → Pages → Source → change from "Deploy from a branch" to "GitHub Actions"
https://github.com/QuantEcon/website/settings/pages

After this lands we can

• Restore @use / @forward Dart Sass directives in assets/main.scss (currently reverted to @import as a workaround)
• Use Jekyll 4.x-only Liquid filters safely in templates
• Drop the github-pages gem dependency entirely

Verification checklist

All verified against the live production site after the Pages source flip (2026-06-10):

• After flipping Pages source: confirm quantecon.org CNAME resolves correctly — Pages API reports build_type: workflow, cname: quantecon.org, https_enforced: true; DNS check successful; apex resolves to the GitHub Pages anycast IPs and the site serves HTTP/2 200. The Jekyll 4.4 Actions build is confirmed live via the /assets/main.css.map fingerprint (200, vs 404 for the legacy-only /assets/css/style.css).
• Confirm redirects in pages/ still work — spot-checked live: /python-lectures/, /form/visitor-application/ (external redirect_to), and /quantecon-rse-joint-intitiative/ all emit correct http-equiv="refresh" stubs.
• Verify all collections build identically — /team/ and /lectures/ are byte-identical to a local Jekyll 4.4 build except the CSS cache-busting timestamp; full sitemap page-inventory diff vs the pre-switch site showed 167 vs 168 paths with only benign differences (/archive/lectures.html — source has commented-out front matter, correctly skipped now; /assets/css/style.css — unreferenced legacy-theme artifact; /assets/main.css.map — new Dart Sass sourcemap).
• Check sitemap.xml and feed.xml output — sitemap <loc> entries are now absolute (fixing a pre-existing spec violation); feed item links are absolute and correct.

Pre-existing issues discovered during verification (not regressions)

• feed.xml is invalid XML: the template does {{ post.content | escape | truncate: '400' }}, and truncating after escaping slices entities like " in half. Fix is to reorder: strip_html | truncate | escape.
• /projects/ 404s and always has (absent from the pre-switch sitemap too), but it is the redirect_to target of /python-lectures/.

Closes #198

[netlify]

✅ Deploy Preview for grand-swan-ca5201 ready!

Name	Link
🔨 Latest commit	113c9e2
🔍 Latest deploy log	https://app.netlify.com/projects/grand-swan-ca5201/deploys/6a28a72050289800088eee88
😎 Deploy Preview	https://deploy-preview-199--grand-swan-ca5201.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Pull request overview

This PR adds a dedicated GitHub Actions deployment workflow for the QuantEcon Jekyll site so production publishing uses the repository’s configured Jekyll 4.4 toolchain instead of the legacy GitHub Pages branch build.

Changes:

• Adds a new Pages deployment workflow that builds the site with Ruby 3.2 and Bundler cache.
• Uses actions/configure-pages, uploads the generated _site artifact, and deploys it via actions/deploy-pages.
• Keeps the existing PR preview workflow separate from production deployment.

[mmcky]

Copilot feedback addressed

Two commits pushed to address the two Copilot security notes:

1. Permissions scoped to deploy job only — pages: write and id-token: write moved off the top-level block and onto the deploy job. Top-level now carries only contents: read. This means the build job (which checks out repo code and runs third-party actions) cannot use deployment credentials even if a step were compromised.

2. workflow_dispatch branch guard — Added if: github.ref == 'refs/heads/main' to the deploy job. A manual trigger from a non-main branch will still run the build job (useful for testing the build) but will never push to the production Pages environment.

---

Why this migration is worth doing

The core problem

The legacy "Deploy from a branch" Pages setup runs builds inside GitHub's gem sandbox, which is pinned to Jekyll 3.10 and LibSass (via jekyll-sass-converter 1.x) regardless of what's in Gemfile. That's a two-major-version gap from what's specified locally.

What Jekyll 4.x unlocks

Feature	Jekyll 3.10 (current production)	Jekyll 4.4 (after this PR)
where_exp / group_by_exp Liquid filters	❌	✅ — already used in #204 (workshops collection)
Dart Sass (@use / @forward)	❌ LibSass only	✅
@import deprecation warnings	None (LibSass ignores them)	Shown — pushes toward modern CSS
Incremental build (--incremental)	Partial	More reliable
Better Liquid error messages	❌	✅

The @use / @forward directives were already written in assets/main.scss as part of the site refresh (#194) but had to be reverted (65163f9) because they fail on the LibSass sandbox in production. Once this PR is merged and Pages is switched to GitHub Actions, those can be restored.

Gemfile control

With the legacy setup, the github-pages gem silently overrides individual gem pins. Every dependency is locked to whatever GitHub chose for their sandbox at build time — meaning a gem update GitHub makes on their end can silently change production behaviour. After this migration we own the full dependency graph via Gemfile.lock.

Reproducibility

Local builds, Netlify preview builds, and production builds all use identical Ruby + Jekyll + gem versions. The "it works locally but fails in production" class of bug goes away.

Summary

This is a small workflow file that removes a large hidden constraint on the tooling we can use. The immediate unblock is Dart Sass @use; longer term it means we can adopt any Jekyll 4.x feature without worrying about the sandbox ceiling.