[dependabot]

Bumps quantecon/actions from 0.12.0 to 0.17.0.

Release notes

Sourced from quantecon/actions's releases.

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)
• Getting started: the alert that told @v0 workflows to copy the templates from v0.14.0 is gone, now that v0 is on v0.15.0, which has the mode and placeholder inputs the templates use. PLAN's release line says @v0 is on v0.15.0. (#246)

Fixed

• restore-jupyter-cache, build-lectures, build-jupyter-cache, publish-gh-pages, setup-environment: no action expands ${{ }} into a run: script any more. Fifty-eight expressions in these five actions put an input, a step's output, a hashFiles() result or the run ID straight into the script text, where bash read a value as shell. Each now reaches the script through env:, quoted, and the run ID is $GITHUB_RUN_ID. So restore-jupyter-cache takes a path holding a $ as written: _build/$x used to restore into, and save from, _build/. It also refuses a key or path that holds a line break, before writing either as a step output, where the line break would have started another output; its key and path descriptions say so. setup-environment quotes environment and environment-name where it runs conda env update. Every other value behaves exactly as before. New harness jobs: unit-custom-seed and unit-custom-restore save and restore a custom key into a path holding a space and a $; unit-line-break shows a line break in either failing the action; and build-html-copy runs html-copy-pdf and html-copy-notebooks, which no harness job turned on. ARCHITECTURE's rule on inputs now has no exceptions, PLAN drops backlog item 18, and TESTING lists the new jobs. (#228)
• build-lectures: html-copy-notebooks copies each notebook under _build/jupyter into _build/html/_notebooks/ at the same path. It copied them flat, but quantecon-book-theme links a page to /_notebooks/<page>.ipynb with the page's directory in it, so a lecture in a subdirectory had a download link that led nowhere, and two lectures with the same name in different directories left one notebook between them. A top-level notebook lands where it did, and no QuantEcon book that copies its notebooks has a lecture in a subdirectory. A failed copy now fails the step, for the PDF too: find … -exec cp … \; ignored a failed cp, so the site was built without the download. The PDF copy stays flat, since the theme links the book's one PDF. The html-copy-notebooks description and the chapter say so, and the chapter drops its caveat on lectures in subdirectories. The harness's build-html-copy job copies a second lecture1.ipynb from a subdirectory, and shows a read-only destination failing each copy. (#217)
• build-jupyter-cache: the failure issue's commands to reproduce each failed build pass --path-output ., as build-lectures does for the action's own builds, so a local repro run from the repository's root builds into _build there. Without it, jb build wrote into the book's own directory, lectures/_build by default, away from where the action, its artifact and its caches put the build. No harness job can file a real issue, so a new one, bjc-alert, runs the alert step's own script against a stand-in for the GitHub API, and checks the command it gives for each failed builder. (#229)
• build-jupyter-cache: a failure is reported on the open issue that carries the first of issue-labels, never on a pull request that carries it. The Issues API lists pull requests too, newest first, and the lookup took the newest item of either kind. So a newer labelled pull request got the report as a comment, no issue was filed, and failure-issue-url pointed at the pull request. The lookup now takes the newest open issue among the first 100 items, and with only pull requests labelled the action files a new issue. The step that checks the alert was filed now also fails unless the URL ends in /issues/<number>, and says so when it is a pull request's. No QuantEcon pull request has ever carried build-failure, the default first label, so a caller who keeps the defaults has not met this. bjc-alert covers a labelled pull request alone, a newer one beside an older issue, an issue after more than 30 newer pull requests, and nothing labelled. PLAN drops backlog item 15, and TESTING lists the new job. (#238)
• restore-jupyter-cache: a build-cache restore that matches, exactly or by prefix, removes the restored <path>/html, and logs how many files went. A build writes over _build/html but removes nothing from it, so a site built over the build cache published again every page and file deleted from the source since the last cache build: a removed lecture's pages, a deleted _static file, image or dataset, and the _pdf/ and _notebooks/ copies that the cache build staged there. The restored HTML saved no work, since a fresh checkout gives every source file a new modification time and Sphinx rewrites every page anyway. _build/jupyter, _build/latex and _build/.jupyter_cache stay, and an execution-cache restore removes nothing. There is no input: a build always rewrites html. A build that offered the PDF or the notebooks from a restored _build/html/_pdf/ or _notebooks/, without html-copy-pdf or html-copy-notebooks, sets those two inputs, which copy them from the restored _build/latex and _build/jupyter; no QuantEcon workflow did. lecture-dp gets the change through @v0 with no edit. The cache-type description, the chapter, ARCHITECTURE's "Two caches", the templates' comments and Getting started's migration steps say so. The harness's build-restore jobs show the removal, with an execution restore as the control. #270 is the second step. (#160)

v0.15.0

Added

• ⚠️ BREAKING build-lectures: an error-outputs input, fail, warn or ignore, and an error-output-count output. After a build that passes, the action reads the notebooks myst-nb wrote to _build/jupyter_execute, outputs included, and reports every error output in them: an annotation on the source file, the traceback in a log group, and a table in the step summary. fail, the default (an empty value), then fails the step, and warn passes it. -W misses these tracebacks when the exception is raised while IPython displays output, such as a figure that fails to draw: the kernel reports the cell as successful, nbclient does not raise, and myst-nb renders the traceback without a warning. So jb build exits 0 and the page is published with the traceback on it, as the Black–Litterman lecture on python-advanced.quantecon.org was from August until its fix in November. ipykernel 7.3.0 fails a cell whose last value cannot be displayed, but output shown through display(), which is how a figure reaches the page, still passes. Errors are allowed where nbclient and myst-nb allow a cell to raise: a cell tagged raises-exception, a notebook whose mystnb metadata sets execution_allow_errors, and a book whose _config.yml sets execute.allow_errors. Notebooks with no source under source-dir, which a restored build cache can carry, are skipped. build-jupyter-cache gets the same error-outputs input and passes it to each build. The new harness job build-display-error-guard stages a display-time error and a raises-exception control, and builds under each value. A site whose pages carry such a traceback now fails its build: fix the cell, tag a deliberate one raises-exception, or set error-outputs: 'warn' while it does. (#247)
• publish-gh-pages: a mode input, so the upload, the deploy and the release assets can each run in a job of their own, and only the job that deploys holds the Pages permissions (finding M1 of the 2026-10-06 review). The action used to upload, deploy and release in one composite step, so a caller had to grant pages: write and id-token: write to the job that executed the notebooks. all, the default, is that behaviour, unchanged. upload uploads build-dir as the run's github-pages artifact and needs only read access. deploy deploys that artifact, from a later job of the same run, with pages: write and id-token: write, and takes no build-dir or cname. release makes the release assets from build-dir, in a job with contents: write, on a tag as before. build-dir is no longer a required input, since deploy takes none. The action checks its inputs first, and fails before anything is uploaded on an unknown mode, a missing build-dir, build-dir or cname with deploy, create-release-assets: 'true' with upload or deploy, or an asset-name with a character other than a letter, digit, ., _ or -. A name with a backslash gave a checksum file that sha256sum --check rejects; the eight consumers that make release assets all use names inside that set. A new mode output gives the mode, and is empty when the inputs were refused. The release assets are unchanged, except that the manifest's strings are now escaped, so a tag with a ", which git allows, gives valid JSON, where it used to give a manifest no parser could read. Their packing moved into scripts/package-release-assets.sh, which the action runs. In CI, as decision 5 on #143 asks, publish-release-packaging runs that script with a stand-in tag and checks each part of the manual's contract: the file names, an archive of the whole site with ./ paths and hidden files, a checksum that sha256sum --check accepts, and a manifest with exactly the documented fields and types. publish-modes runs the action with contents: read alone. It asserts that upload uploads the site, that release skips off a tag, and that each refused combination fails with an empty mode, before anything is uploaded. A real deploy and a release upload are the staged canary's to prove. (#233)
• preview-netlify, preview-cloudflare, templates/ci.yml: a placeholder input, which posts the pull request's preview comment within seconds of a push, before the build has finished, and a placeholder job in ci.yml that runs it (#153). Until now the comment came only after a successful deploy, minutes later. With placeholder: 'true' the action decides as for a deploy, so a fork's or Dependabot's pull request gets nothing, then installs and deploys nothing. It builds the preview URL from the pull request's number, from a new netlify-site-name input on preview-netlify and from project-name on preview-cloudflare, and reads the changed lectures from the API's list of the pull request's files, by change detection's rules, so its job needs no checkout, no container and no secret. The comment is headed "⏳ … Preview Building", says that its links show the last push deployed until this one's deploy finishes, and carries the same hidden marker, so the deploy's comment replaces it in place; the placeholder never replaces the deploy's comment for its own commit. The token, the site or account ID and build-dir are now required for a deploy only: a run that would deploy without one fails at a new input check, before anything is installed, with an error naming it. A step that passes them, as every caller does, deploys as before. The preview-comment harness job now runs that check for 20 cases, and the placeholder's comment against the API stand-in, and preview-wiring runs a deploy without its token or build-dir, and invalid placeholder inputs, through each action.

Changed

• preview-cloudflare, deploy-cloudflare: the pinned wrangler moves from 4.156.0 to 4.156.1, through Dependabot's lockfile bump. The harness installs it from both lockfiles and runs it. (#259)
• templates/publish.yml: builds and deploys in separate jobs, as ci.yml does since #232. build builds in the container with contents: read and ends with publish-gh-pages mode: upload. deploy needs build, runs on ubuntu-latest with no checkout or container, holds only pages: write and id-token: write, and runs mode: deploy in the github-pages environment. The optional release assets move to a commented release-assets job with contents: write, which runs mode: release on a tag once the deploy has succeeded. It takes the site from an html artifact that a commented step in build uploads before the Pages upload, hidden files included, so the archive holds what it did. The template needs the release that adds mode: an earlier @v0 ignores the input, and both jobs fail. (#233)
• templates/ci.yml, templates/cache.yml, templates/publish.yml: the pull request preview is deployed from a job that runs no notebook code, and no template leaves the job's token in git's config for later steps (finding M1 of the 2026-10-06 review). Building the lectures runs code the repository does not fully control, and it used to share a job with the step that hands the Netlify or Cloudflare token to the deploy CLI. ci.yml now has three jobs. build (renamed from preview) builds in the container with contents: read and no secrets, and uploads _build/html as the html artifact, hidden files included. deploy needs build, has no container, holds the provider secrets and pull-requests: write, sets up Node 24 and runs only the preview action on the downloaded site. pdf-check now needs build too, so it runs beside the deploy rather than after it. Every checkout in the three templates sets persist-credentials: false. Change detection in deploy fetches the history it needs from GitHub with no credentials, which a public repository allows; a private repository sets fetch-depth: 0 on deploy's checkout, as its comment says. A site that copies the new ci.yml and makes the old job a required status check must require build in place of preview: no job is called preview any more, so until it does its pull requests wait for a check that never reports. pdf-check and deploy are both skipped when build fails, so either needs build required beside it. Two harness jobs, preview-site-handoff and preview-deploy-job, run the hand-off: the site must arrive whole, hidden files included, and from a shallow checkout with no stored credentials, change detection must list the files GitHub lists for the pull request. (#232)
• Container images: the Ubuntu base is pinned by digest, and nothing rebuilds the images on a schedule any more, as decided on #234. Until now build-containers.yml rebuilt both images every Monday. When ubuntu:24.04 had not moved, BuildKit replayed every layer from the cache and republished the same image (four of the seven Mondays from 2026-08-24 to 2026-10-05), while the READMEs, docs/CONTAINER-GUIDE.md and docs/dev/ARCHITECTURE.md promised weekly security updates. When it had moved, the images' floating packages re-resolved with no pull request, which is how plotly 7 reached the lean image (#222). Both Dockerfiles now pin ubuntu:24.04@sha256:fe81560…, the digest the current :latest images were built on, so the pin changes neither image. Dependabot proposes each new 24.04 digest as one pull request for both images, which builds and smoke-tests them before :latest moves, and ignores 26.04 and any other release. OS updates therefore arrive whenever Canonical republishes the base, every few weeks, reviewed. Those docs and CONTRIBUTING.md now say so, and point to #129 for what the pin does not make reproducible. On every harness run, validate-containers.yml checks that each image pins its base by digest and that both pin the same one (scripts/check-base-pins.sh). The lecture matrix, test-containers-lectures.yml, which the weekly build used to trigger, now runs weekly on a schedule of its own against :latest (Monday 02:00 UTC), so drift in the lecture repos against an unchanged image is still caught. (#235)

Deprecated

• deploy-cloudflare: require-access, and leaving out both it and visibility, are still accepted in this release, with the same warning on every run. v0.14.0 said they would become errors in this release; that moves to v0.16.0, so that sites have a release's notice. Add visibility now. (#177)

... (truncated)

Changelog

Sourced from quantecon/actions's changelog.

[0.17.0] - 2026-11-10

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

... (truncated)

Commits

• fae622c release: v0.17.0 (#289)
• 6b2886c ci(containers): the lecture matrix files a cancelled run only when no newer r...
• e38afc2 ci(containers): move :latest only once main's build has passed the smoke test...
• 5a80d5c feat(setup-environment): install-latex installs from the LaTeX package cache,...
• d89b021 feat(setup-latex): install TeX Live from a cache of the downloaded packages (...
• e313f9f fix(preview-cloudflare): build deploy-url on the address the deployment is se...
• 7fbb78f feat(restore-jupyter-cache): the templates restore the execution cache, keyed...
• e40924a release: v0.16.0 (#278)
• 5b2e477 fix(restore-jupyter-cache): remove the restored html after a build-cache rest...
• a835362 fix(deploy-cloudflare): remove require-access, and require visibility (#177) ...
• 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)