[dependabot]

Bumps quantecon/actions from 0.12.0 to 0.19.0.

Release notes

Sourced from quantecon/actions's releases.

v0.19.0

Added

• restore-gh-pages and templates/restore.yml: puts a GitHub Pages site back as one of the repository's releases holds it, without a build, from the archive, checksum and manifest that publish-gh-pages attaches on a tag. The action downloads the release's archive and checksum with gh, checks the archive's SHA-256 before anything is extracted, refuses an archive that holds anything but files and directories, and gives the extracted site as build-dir, with the commit it was built from as commit. It reads only the repository's own releases, needs only contents: read, and finds the archive by its tag unless asset-name is given. The template, run by hand on the default branch with the release's tag, hands the site to publish-gh-pages to deploy, in publish.yml's pages concurrency group. The next publish replaces the restored site. (#27)

Changed

• Container images: sphinx-exercise moves from 1.2.1 to 1.2.2 in both images, which the full image pins and the lean image takes as its floor. The patch release writes a captioned figure inside an exercise or solution as \begin{figure}[H], as Sphinx does inside its own admonitions, so a PDF build no longer stops there with Not in outer par mode. HTML output is unchanged. Both images were smoke-tested before :latest moved, and the lecture matrix then passed on all eight legs. (#312)

Fixed

• ⚠️ BREAKING build-lectures: a jupyter build under -W --keep-going, the default extra-args, now fails on a warning, as the other builders do. It used to pass every warning. sphinx-tojupyter's JupyterBuilder.finish() calls exit() with 0 inside Sphinx's build, before Sphinx turns the warnings that --keep-going counted into exit status 1. So jb build exited 0 whatever the build warned about, a cell that raised included. The release gate's staged-failure self-test showed it: only the error-output check caught the raised cell. The build step now keeps a copy of jb build's stderr, Sphinx's warning stream. For the jupyter builder, when jb build exits 0 with both -W and --keep-going in extra-args, it fails the step on any warning in it, and lists each in a log group. The failure report then prints the failed notebooks' tracebacks, as for any failed build. -W alone already failed at the first warning, and without -W nothing changes. build-jupyter-cache gets the same through build-lectures@v0; it builds jupyter first, so that build is the one that reads and executes the pages. The error-output check now tells a cell that raised, after which no code cell ran, from one whose output raised while it was displayed, after which one did. It says which in its annotation and in a Cause column in the step summary, where it used to say "The kernel reported this cell as successful" of both. The new harness job build-jupyter-warning-guard shows a clean jupyter build passing, a cell that raises failing the build step, the same warnings passing without -W, and the check's wording. The lecture matrix found one warning, in three lecture repositories: a tojupyter_static_file_path entry naming a directory the book does not have, which warns tojupyter_static_path entry … does not exist. Their pull requests drop that entry, and no other QuantEcon caller's jupyter build logs a warning. To migrate: fix each warning the build step lists, such as by dropping that entry, or set extra-args without -W for the jupyter build while you do. (#300)

v0.18.0

Added

• preview-workers: a new action that previews a pull request on an existing Cloudflare Worker, as Cloudflare moves static sites from Pages to Workers. It uploads the built site as a new version of the Worker with wrangler versions upload --preview-alias pr-<number>, which never changes what the Worker serves in production, at https://pr-<number>-<worker-name>.<account-subdomain>.workers.dev, and comments on the pull request as preview-netlify and preview-cloudflare do, with a comment of its own. It has their trust gate, dispatch-alias, placeholder and outputs. deploy-url is built from the inputs and checked against wrangler's record of the upload: a wrong account-subdomain, or a Worker whose preview URLs are off, fails the job rather than post a link that cannot load. deployment-url is the version's own preview URL, which keeps showing that push. The wrangler config is generated for each run by the writer deploy-cloudflare uses, now in scripts/, with no change to deploy-cloudflare. The token is an account-owned API token scoped to the one Worker, which the chapter shows how to make. (#145)

Changed

• Container images: builds of main outside the kept window are now deleted from GHCR. A new monthly workflow, prune-images.yml, keeps main's newest 10 builds and every version of the last 90 days, tagged or not, so every build of the last 90 days; the newest builds are the rollback targets. It keeps a dispatch from a branch for 14 days. It always keeps :latest, a pull request's candidates, every digest in .github/container-pins.txt, any version carrying a tag it does not own, and every manifest these list. Until now nothing was deleted: 338 versions of quantecon had built up, and 221 of quantecon-build. A workflow that pins an image by digest keeps working while that build is kept. To keep a pin for longer, add its digest to .github/container-pins.txt in a pull request, or have the version tagged with a name that does not end in -<7 hex digits>. The one pin known in QuantEcon, quantecon-build in the two theme test repositories, is in the file. A dispatch is a dry run unless told otherwise, a pull request that changes the pruner lists what it would delete, and a run with more than 50 versions of an image to delete deletes none. (#277)
• preview-netlify, preview-cloudflare, deploy-cloudflare: through Dependabot's lockfile bump, preview-cloudflare and deploy-cloudflare pin wrangler 4.158.0, up from 4.156.1, and preview-netlify pins netlify-cli 27.16.2, up from 27.16.1. preview-workers ships with wrangler 4.158.0. The harness installs each from its lockfile and runs it. (#294)
• publish-gh-pages: softprops/action-gh-release, which attaches the release assets, moves from 3.0.3 to 3.0.4, through Dependabot's bump. The patch release classifies GitHub API errors more safely. (#295)
• Container images: quantecon-book-theme moves from 0.22.1 to 0.22.2 in both images, through Dependabot's bump. The patch release's dark-mode button is labelled "Toggle dark mode", and a site that sets no author no longer shows "Author name not set" in its page header. Both images were smoke-tested before :latest moved. (#293)

Documentation

• Releases (CONTRIBUTING, Staged Releases): a release that changes an action passes the release gate before v0 moves. The gate is gate.yml in the canary, QuantEcon/test-actions-lecture-intro, dispatched on its main with the candidate, which it refuses unless it is reachable from main or a v* tag. It checks the candidate out and runs the actions from that checkout on a fixture whose image is pinned by digest and whose pages read nothing from the network: build-jupyter-cache cold with all three builders, its siblings at the candidate too; both cache restores; both previews and a GitHub Pages deploy, each checked for the candidate's build. It replaces the canary pull request and cache.yml dispatch that a staged release ran by hand, which now stage only what the gate does not reach: a preview's pull-request half, setup-environment outside a container, setup-latex, deploy-cloudflare, preview-workers, and a release's own scenarios. A red gate run from main assigns a release-gate issue in the canary to whoever dispatched it. TESTING.md describes the gate, and PLAN.md drops items 0a, 0b and 0d. (#135, #136)

v0.17.0

Added

• setup-latex: a new action that installs TeX Live, or any apt packages, on a standard Ubuntu runner, from a cache of the downloaded .deb archives. A plain apt-get install downloads TeX Live from the runner's Ubuntu mirror on every run, 1.1 GB for the usual lecture list, and a slow mirror stalls that without ever failing: since September, 12 of 220 such steps in the lecture repositories took over 5 minutes, and the slowest ran for nearly 6 hours. The cache key hashes the packages installed on the host, so an exact hit installs the archives as local files with no apt-get update and no download. A fallback restore, as after a new runner image, downloads only what the cache lacks. It caches archives, not installed files, so dpkg runs TeX Live's maintainer scripts as before. download-timeout-minutes, 30 by default, stops a download that runs longer, and '0' sets no limit. The cache is saved after the install, except on an exact hit or from a tag. The 15 lecture repositories that inline their own apt-get install texlive-… step can switch with a one-step change, which the chapter shows. The work is in scripts/latex-packages.sh, for setup-environment's install-latex to share. (#224)

Changed

• build-jupyter-cache, restore-jupyter-cache: the execution cache's key hashes the environment files too, as jupyter-cache-<hash of environment>-<hash of environment-update>-<hash of the lectures>-<run id>, and a restore falls back to jupyter-cache-<env>-<update>-, then jupyter-cache-<env>-: the build cache's fallbacks. It used to hash the lectures alone and fall back to any execution cache. .jupyter_cache checks each notebook against its code, but not against the packages that executed it, so a pull request that changed the environment file restored outputs made with the old packages, re-executed nothing, and passed. Now it misses and executes every lecture, as it does with the build cache. environment and environment-update apply to both cache types. A workflow that already restores cache-type: execution misses once after v0 moves, until its next cache build, and one that also sets fail-on-miss: 'true' should run its cache workflow once then; no QuantEcon workflow restores execution. The harness's new unit-exec-env-miss restores the seed's lectures under another environment file, and must miss. (#270)
• templates/ci.yml, templates/publish.yml: both restore cache-type: 'execution', _build/.jupyter_cache alone, instead of the build cache. The build cache brings back what the last cache build made, including what the source has deleted since. Since #160 the restore removes its html, but a build that makes the notebooks or the PDF over it can still copy a removed lecture's notebook, or a deleted PDF, into the site. The execution cache leaves nothing of the kind, and is several times smaller, so a restore downloads less, and a pull request's save-cache stores less. The rest of _build saves no work: a fresh checkout makes Sphinx rewrite every page. A repository that copied an older template sets cache-type: 'execution' on the restore step of both. build-jupyter-cache still saves the build cache, since restore-jupyter-cache's default restores it; whether it stops, or becomes opt-in, goes with a later change of that default (review M3). (#270)
• setup-environment: install-latex installs the LaTeX packages as setup-latex does, through the same script: from a cache of their downloaded archives, keyed on cache-version, the list and the packages installed on the host, with no apt-get update and no download on an exact hit. It used to download them from the runner's Ubuntu mirror on every run, which a slow mirror can stall for hours. A new output, latex-cache-hit, says which way they came. On a run that downloads, apt-get update and the download together are now stopped after 30 minutes, with no input to change it: a download that runs past 30 minutes now fails, where it used to finish slowly. No QuantEcon repository passes install-latex. build-jupyter-cache passes it for a pdflatex build in standard mode, and its three QuantEcon callers all run in a container. A repository that needs another limit can install LaTeX with setup-latex and its download-timeout-minutes instead. cache-version now keys the LaTeX cache too, so a bump also downloads the packages afresh. Each entry in the list must be an apt package name, so an option such as --no-install-recommends, which apt used to take from the file, now fails the job. The messages for a missing or empty list now name the file. (#224)
• Container images: :latest moves only once the image it will point at has passed the smoke test. Until now the merge's own build pushed :latest directly, and test-container.yml tested it afterwards. That build is not the image its pull request tested: it rebuilds the changed layers, whose floating packages resolve again, and a dispatch or a direct push to main was tested by nothing. build-containers.yml now pushes only candidates, main-<sha> and one main-<date>-<time>-<sha> tag for the run, and calls test-container.yml on them twice, for the smoke test and for the size report. When every smoke test passes, a new promote job points :latest at the digest each build pushed, all the images together, with docker buildx imagetools create, through a new scripts/promote-image.sh. The script first checks that each candidate tag still resolves to the digest pushed, then that :latest does after the move, and the job's step summary has the digests pushed, promoted and replaced, with the rollback command. A failed smoke test or promotion leaves :latest where it was and opens the failure tracking issue. A failed size report alerts too, but cannot hold a promotion back, since it fails on the measurement, not the image. A cancelled run alerts only when no newer run has superseded it. On any branch but main the promotion is a dry run, and validate-containers.yml dry-runs it on each pull request's candidates, with a self-test of the script on every harness run. test-container.yml loses its workflow_run trigger and its own alert, now the build run's, and takes a checks input. The lecture matrix starts only after a run on main, since a branch's run moves nothing. :latest moves a few minutes later after a merge, by the smoke test's run time. Every main-* tag is kept as a rollback target. The sed tag lists in build-containers.yml are rewritten, so .github/actionlint.yaml and its ignores for them go. (#142)

Fixed

• preview-cloudflare: deploy-url, and with it the comment's preview URL and every lecture link, is built on the address Cloudflare serves the project at, which it keeps apart from the project's name and which can differ from <project-name>.pages.dev. The address comes from the deployment's own URL in wrangler's record of the deploy, the pages-deploy-detailed line it writes to WRANGLER_OUTPUT_FILE_PATH, so no other call is made, and the alias URL is still built, stable across pushes, as #14 made it. deployment-url is read from the same record, in place of the first matching URL in wrangler's log. When the record gives no URL of the form https://<hash>.<name>.pages.dev, the step warns, deploy-url falls back to <project-name>.pages.dev as before, and deployment-url is empty. When the address is not <project-name>.pages.dev, a notice says so: a comment posted with placeholder: 'true' still links there, having no deploy to ask, until the deploy's comment replaces it (#216).

v0.16.0

Added

• CI: the harness gate lints this repository's own workflows with actionlint. Until now it linted only the templates and the manual's examples, so .github/workflows/ had never been linted. The first run found 11 problems, all shellcheck findings at style or info level, and none from actionlint's own rules. Four are fixed with rewrites that print the same output. Three are sed calls that edit each line of a multi-line value, where SC2001's ${var//} cannot apply, so each has a # shellcheck disable with that reason. The other four are in build-containers.yml, which this change leaves alone because a merge that edits it rebuilds both images and moves :latest. .github/actionlint.yaml ignores them for that file only, until #142's phase 2 changes it. actionlint skips run: scripts when it finds no shellcheck, so the gate now fails if the runner image has none, and logs its version. TESTING.md and AGENTS.md give the same check to run locally. (#100)
• CI: the harness gate shellchecks each action's run: scripts, and scripts/*.sh, through a new scripts/lint-shell.py, since actionlint never reads an action.yml. The script reads every */action.yml with PyYAML, runs shellcheck at warning severity on each run: script whose shell is bash or sh, and reports each finding at its line in the action.yml. It also fails on any ${{ }} left in a run: script, an action's or a workflow's. #228 moved every one in the actions into env:, and the workflows had none, so AGENTS.md's rule now holds from here on. At warning severity it found nothing else: the 56 run: scripts and the 9 scripts/*.sh pass with shellcheck 0.11.0. The two scripts under containers/ are left out, since a change there rebuilds both images. (#100)

Changed

• restore-jupyter-cache: cache-type accepts only build or execution, and save-cache and fail-on-miss only 'true' or 'false'; path must not be empty. Anything else fails the run in its first step, on every call, a custom key's included, before anything is restored or registered for saving. The steps compared these values exactly, but their conditions compared them case-insensitively. So save-cache: 'True' registered the job-end save under the read-only key, which has no run ID: the first run saved under it, every later run matched it exactly and saved nothing, and the pull request's cache stopped updating without a word. A typo such as cache-type: exec restored the whole build cache, and fail-on-miss: yes was false. An empty path restored the execution cache into /.jupyter_cache, and failed inside actions/cache for the build cache. An unquoted true or True is unaffected, since YAML reads it as a boolean and the action receives 'true'. No QuantEcon workflow passes a value outside these. Each input's description names its accepted values, and a new harness job, unit-input-values, shows each refused value failing the action where a control passes. It also makes #160's cache-type: execution safer to adopt: a mistyped value can no longer bring the build cache back unnoticed. (#236)
• Every action: an input that is one value fails the run in the action's first step if it holds a line break, and every input printed in an error or a warning is escaped. The runner reads each line a step prints that starts with :: as a workflow command, so an input such as environment or build-dir whose second line began with :: issued that command when the action printed it, and a value such as 50%25 printed in an annotation showed as 50%. Refused now: every input but build-lectures' extra-args, which is split on whitespace and is now printed with its line breaks as spaces; build-jupyter-cache's builders, issue-labels and issue-assignees, which are lists; and the tokens and IDs passed as secrets, which no action prints. deploy-cloudflare already refused a line break in each of its inputs but the secrets, and its message for build-dir is now the shared one. Both the check and the escaping are scripts/workflow-command.sh, which each step sources from $GITHUB_ACTION_PATH/../scripts/, in place of the copies in build-lectures, restore-jupyter-cache, both preview actions, scripts/preview-decide.sh and scripts/detect-changed-lectures.sh. Every other value behaves as before, and no QuantEcon workflow passes a line break in any of these inputs. New harness jobs: workflow-command-helper tests the file, and inputs-line-break shows each action failing in its first step on one. Copilot's review of #265 found the first case, in setup-environment. (#267)

Removed

• ⚠️ BREAKING deploy-cloudflare: require-access is removed, and visibility is required, as the v0.14.0 and v0.15.0 deprecations said. Passing require-access now fails the job in its first step, with a message that says what to use instead, and so does leaving out visibility, which used to check the site as private with a warning. require-access: 'false' was the only way to turn the checks off, and that goes with it: every deploy is checked before the upload, after the deploy and on the alias, as private or public. The visibility output is set on every run whose inputs pass. To migrate: replace require-access: 'true', or neither input, with visibility: private. For require-access: 'false', use visibility: public and remove team-domain if the site is public, or visibility: private if it is behind Access. The chapter's "Moving from require-access" table gives each form. Two QuantEcon workflows call the action, both pinned to v0.12.0 and passing neither input, so each needs visibility: private when it moves to this release. dc-inputs shows both failures. (#177)

Documentation

• Developer docs (#178): docs/dev describes the project as it is. ARCHITECTURE.md is the current design: the parts, and why the actions are composite, the environment an image, the caches keyed as they are, deploys kept in jobs of their own, installs pinned, inputs passed through env:, failures alerted and the manual generated. The pitch, the performance targets, the migration plan, the resolved questions and the success criteria are gone. TESTING.md is how testing works now: the harness's gate and summary, its fixtures, what each action's jobs cover, the container checks, the canary, local checks, and what nothing covers. It said the preview actions and publish-gh-pages had no tests, which the harness's preview-*, publish-release-packaging and publish-modes jobs had made untrue. PLAN.md keeps the current state, consumers, open priorities, dependency policy, open issues and rollout, and drops the closed items and the history. A root AGENTS.md, which Copilot code review and other agents read, replaces .github/copilot-instructions.md, pointing at docs/dev instead of repeating it. CONTAINER-VALIDATION.md describes the lecture matrix as it runs, when, what it builds and how to read a run, without the February 2026 results. No container size is written into the docs any more: like the user manual, the dev docs point at each Test Container run's size report (#201). tests/README.md and CONTRIBUTING's doc-update table follow. (#192)

... (truncated)

Changelog

Sourced from quantecon/actions's changelog.

[0.19.0] - 2026-11-11

Added

• restore-gh-pages and templates/restore.yml: puts a GitHub Pages site back as one of the repository's releases holds it, without a build, from the archive, checksum and manifest that publish-gh-pages attaches on a tag. The action downloads the release's archive and checksum with gh, checks the archive's SHA-256 before anything is extracted, refuses an archive that holds anything but files and directories, and gives the extracted site as build-dir, with the commit it was built from as commit. It reads only the repository's own releases, needs only contents: read, and finds the archive by its tag unless asset-name is given. The template, run by hand on the default branch with the release's tag, hands the site to publish-gh-pages to deploy, in publish.yml's pages concurrency group. The next publish replaces the restored site. (#27)

Changed

• Container images: sphinx-exercise moves from 1.2.1 to 1.2.2 in both images, which the full image pins and the lean image takes as its floor. The patch release writes a captioned figure inside an exercise or solution as \begin{figure}[H], as Sphinx does inside its own admonitions, so a PDF build no longer stops there with Not in outer par mode. HTML output is unchanged. Both images were smoke-tested before :latest moved, and the lecture matrix then passed on all eight legs. (#312)

Fixed

• ⚠️ BREAKING build-lectures: a jupyter build under -W --keep-going, the default extra-args, now fails on a warning, as the other builders do. It used to pass every warning. sphinx-tojupyter's JupyterBuilder.finish() calls exit() with 0 inside Sphinx's build, before Sphinx turns the warnings that --keep-going counted into exit status 1. So jb build exited 0 whatever the build warned about, a cell that raised included. The release gate's staged-failure self-test showed it: only the error-output check caught the raised cell. The build step now keeps a copy of jb build's stderr, Sphinx's warning stream. For the jupyter builder, when jb build exits 0 with both -W and --keep-going in extra-args, it fails the step on any warning in it, and lists each in a log group. The failure report then prints the failed notebooks' tracebacks, as for any failed build. -W alone already failed at the first warning, and without -W nothing changes. build-jupyter-cache gets the same through build-lectures@v0; it builds jupyter first, so that build is the one that reads and executes the pages. The error-output check now tells a cell that raised, after which no code cell ran, from one whose output raised while it was displayed, after which one did. It says which in its annotation and in a Cause column in the step summary, where it used to say "The kernel reported this cell as successful" of both. The new harness job build-jupyter-warning-guard shows a clean jupyter build passing, a cell that raises failing the build step, the same warnings passing without -W, and the check's wording. The lecture matrix found one warning, in three lecture repositories: a tojupyter_static_file_path entry naming a directory the book does not have, which warns tojupyter_static_path entry … does not exist. Their pull requests drop that entry, and no other QuantEcon caller's jupyter build logs a warning. To migrate: fix each warning the build step lists, such as by dropping that entry, or set extra-args without -W for the jupyter build while you do. (#300)

[0.18.0] - 2026-11-10

Added

... (truncated)

Commits

• eb965b9 release: v0.19.0 (#313)
• c5d2e44 deps: sphinx-exercise 1.2.2 in both images (#312)
• 23125a9 fix(build-lectures): a jupyter build fails on its warnings under -W --keep-go...
• 4b585c3 docs: point the CHANGELOG footer at the pages that replaced the migration gui...
• 2315a84 ci(harness): restore-round-trip uploads no github-pages artifact (#27) (#309)
• 7301d89 docs(plan): v0 is on v0.18.0; every publish-gh-pages consumer makes release a...
• 38ab846 feat(restore-gh-pages): restore a GitHub Pages site from a release (#27) (#306)
• f627321 release: v0.18.0 (#304)
• 2ed1629 deps: Bump the conda group across 2 directories with 1 update (#293)
• 0efa52d ci: Bump the github-actions group across 2 directories with 2 updates (#295)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[netlify]

✅ Deploy Preview for taupe-gaufre-c4e660 ready!

Name	Link
🔨 Latest commit	05c8806
🔍 Latest deploy log	https://app.netlify.com/projects/taupe-gaufre-c4e660/deploys/6af8dcc91e85182e80e0fede
😎 Deploy Preview	https://deploy-preview-867--taupe-gaufre-c4e660.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.