[dependabot]

Bumps quantecon/actions from 0.12.0 to 0.16.0.

Release notes

Sourced from quantecon/actions's releases.

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)

Documentation

• docs/dev/PLAN.md: caught up with wave 1 of #246 and the v0.13.0 and v0.14.0 releases. Since #240 a dispatched or scheduled run can exercise the preview deploy, so the statements that it could not are gone, and 0c's prerequisite is recorded as met: what remains is the canary's own changes (#135, #136). The release state says v0 is on v0.14.0, and the eight exactly pinned call sites still read @v0.12.0. Backlog item 18 counts five actions with ${{ }} in run: scripts, not seven, and item 15 lists #238 as left and #243 as done. The rows for #222, #227 and #230 record their closure, and #232, #233, #236, #238, #239, #243, #246 and #247 get rows. (#246)
• User manual (#178): the cross-cutting chapters, in docs/user/. getting-started.md sets up a lecture repository from the templates, gives what each job of ci.yml and publish.yml does and holds, covers the changes a site makes to them (downloads, the PDF check, release assets, a standard runner, a custom domain, Cloudflare Pages), and moves an existing repository over, cache first, with its rollback. composition.md follows the chain from the cache build to a preview or publish, what passes between the steps, and the settings that must agree. containers.md covers the two images: what each holds, which to use, how to use and pin one, and when they change, now that nothing rebuilds them on a schedule (#235). It does not call them public, since an anonymous pull is refused (#129), and points at each Test Container run's size report rather than quote sizes that drift. versioning.md covers @v0 against an exact release, how a release reaches a repository, and that build-jupyter-cache runs its two siblings at @v0 whatever it is pinned to. security.md covers fork pull requests and pull_request_target, what each template job can reach, the deploy jobs of #232 and #233, and what the actions themselves do. templates/README.md and the three container READMEs become signposts, and the container READMEs' build, update and test sections move to a new docs/dev/CONTAINERS.md. docs/MIGRATION-GUIDE.md and docs/CONTAINER-GUIDE.md are removed: their content is in these chapters, and the per-repository migration notes are in PLAN's rollout section. The root README points at the manual, and CONTRIBUTING's doc-update table names each chapter. (#191)
• SECURITY.md: how to report a vulnerability, privately through the repository's Security tab, and what is in scope: the actions, the templates and the container images. The harness gate treats a root SECURITY.md as documentation, as it does the README, so a change to it alone does not run the harness. (#191)
• docs/dev/PLAN.md: backlog item 6 is done (#253, #258), and the rows for #232, #233, #235, #239 and #247 record their closure. (#191)

Fixed

• build-lectures, build-jupyter-cache: the failure artifacts hold the hidden directories they promise. upload-artifact leaves out every path whose name starts with a dot unless include-hidden-files is set, even a path it is given by name, and neither upload set it. So build-lectures' upload-failure-reports artifact held the reports directories without _build/.jupyter_cache, which its path list names, and build-jupyter-cache's build-cache-<run id> artifact, described as the whole _build directory, held it without .jupyter_cache and .doctrees. Both uploads now set include-hidden-files: true. The harness's build-fail-guard and bjc-fail-guard jobs now download each artifact and check it for those directories. (#243)
• preview-netlify, preview-cloudflare: each action now finds its own comment on a pull request with more than 30 comments, and never edits anyone else's (finding M2 of the 2026-10-06 review). Both looked for their earlier comment with one unpaginated listComments call, which returns the first 30, so on a pull request that already had 30 comments before its first preview, every push posted another. They also took any comment that contained the heading, a person's included. The two copies of the comment script are now one, scripts/preview-comment.cjs, loaded from a path resolved from $GITHUB_ACTION_PATH, so it loads in a container job too. It reads every page of comments, and updates only one by github-actions[bot] that starts with a hidden line, <!-- quantecon-preview:netlify --> or <!-- quantecon-preview:cloudflare -->, or with the heading, as comments posted before this change do, so an open pull request keeps its comment. Where several match, it updates the newest. The comment otherwise renders exactly as before. A new harness job, preview-comment, runs each action's own comment steps against a stand-in for the GitHub API. It checks each body against the one the old scripts rendered for the same inputs, and that the action finds its comment after 150 others and passes over a person's or another app's. (#153)

v0.14.0

Added

... (truncated)

Changelog

Sourced from quantecon/actions's changelog.

[0.16.0] - 2026-11-07

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

... (truncated)

Commits

• 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) ...
• 558ad65 docs(setup-environment): give the real reason container mode caches nothing (...
• 87c428a fix(build-jupyter-cache): the failure alert lands on an issue, and its repro ...
• 879ecc5 fix(build-lectures): keep each notebook's path in html-copy-notebooks, and fa...
• 9644f17 fix: refuse a line break in each single-value input, and escape every annotat...
• 19890f8 ci(harness): shellcheck the actions' run: scripts and scripts/*.sh in the gat...
• 8c12d4f fix(restore-jupyter-cache): refuse values outside each input's accepted set, ...
• ea01c01 fix: pass every value to the actions' run: scripts through env: (#228) (#265)
• 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)