chore: update rhiza to v1.6.0 #912
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,5 +20,5 @@ on: | |
|
|
||
| jobs: | ||
| benchmark: | ||
| uses: jebel-quant/rhiza/.github/workflows/rhiza_benchmark.yml@v1.6.0 | ||
| secrets: inherit | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -26,5 +26,5 @@ on: | |
|
|
||
| jobs: | ||
| ci: | ||
| uses: jebel-quant/rhiza/.github/workflows/rhiza_ci.yml@v1.6.0 | ||
| secrets: inherit | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,5 +28,5 @@ on: | |
|
|
||
| jobs: | ||
| marimo: | ||
| uses: jebel-quant/rhiza/.github/workflows/rhiza_marimo.yml@v1.6.0 | ||
| secrets: inherit | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,5 +28,5 @@ on: | |
|
|
||
| jobs: | ||
| weekly: | ||
| uses: jebel-quant/rhiza/.github/workflows/rhiza_weekly.yml@v1.6.0 | ||
| secrets: inherit | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| repository: "jebel-quant/rhiza" | ||
| ref: "v1.6.0" | ||
|
|
||
| profiles: | ||
| - github-project | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,8 +1,7 @@ | ||
| # LaTeX Paper | ||
|
|
||
| This folder is where the `paper` bundle expects your LaTeX sources. `make paper` | ||
| compiles them to a PDF, and `make paper-clean` removes the build artifacts. | ||
|
|
||
| ## Layout | ||
|
|
||
|
|
@@ -34,22 +33,30 @@ common case. Name it `main.tex` if you have several and want to be explicit. | |
|
|
||
| | target | does | | ||
| | --- | --- | | ||
| | `make paper` | compiles the root document to a PDF beside its source | | ||
| | `make paper-clean` | removes each document's PDF and auxiliary files | | ||
|
|
||
| The engine reruns the TeX pass and bibtex until the cross-references and citations | ||
| converge, so one invocation is enough however many passes the document needs. `paper` | ||
| runs with this folder as the working directory, so `\input` paths are relative to it | ||
| and the output lands beside the source rather than at the repository root — which is | ||
| what lets the book publish the PDF with no copy step. | ||
|
|
||
| `paper-clean` is scoped by document stem: `paper.tex` authorises deleting `paper.pdf` | ||
| and `paper.log`, while a `figures/diagram.pdf` you committed has no `.tex` beside it | ||
| and survives. | ||
|
|
||
| ## Requirements | ||
|
|
||
| [tectonic](https://tectonic-typesetting.github.io/), a single binary that resolves | ||
| the packages a document cites out of its own web bundle and caches them — so there is | ||
| no TeX distribution to install and no package list to keep in step with your | ||
| `\usepackage` lines. A cold cache needs the network; after that it does not. | ||
|
|
||
| Without tectonic on `PATH` both targets skip, with that as the reason, rather than | ||
| failing — so a contributor who does not build the paper is not blocked by it. Pass | ||
| `--strict` to turn the skip into a failure where the paper *must* build, such as in | ||
| CI, which is what the shipped pipelines do. | ||
|
|
||
| ## Configuration | ||
|
|
||
|
|
@@ -63,37 +70,59 @@ paper-folder = "manuscript" | |
|
|
||
| ## Continuous integration | ||
|
|
||
| The `github-paper` bundle adds a workflow that compiles the paper and publishes it. It | ||
| triggers only on changes under `docs/paper/**`, so it costs nothing until there is a | ||
| paper to build. It installs tectonic itself; the compile is the same `paper` task you | ||
| run locally, under `--strict`, so a runner that never got the engine fails instead of | ||
| reporting a skipped build as success. | ||
|
Comment on lines
+73
to
+77
There was a problem hiding this comment. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- tracked candidate files ---'
git ls-files 'docs/paper/README.md' '.github/workflows/rhiza_paper.yml'
printf '%s\n' '--- README context ---'
cat -n docs/paper/README.md | sed -n '60,105p'
printf '%s\n' '--- workflow outline and context ---'
if command -v ast-grep >/dev/null 2>&1; then
ast-grep outline .github/workflows/rhiza_paper.yml
fi
cat -n .github/workflows/rhiza_paper.yml | sed -n '1,220p'Repository: tschm/TinyCTA Length of output: 4729 🏁 Script executed: #!/bin/bash
set -eu
url='https://raw.githubusercontent.com/Jebel-Quant/rhiza/v1.6.0/.github/workflows/rhiza_paper.yml'
tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT
curl --fail --silent --show-error "$url" > "$tmp"
printf '%s\n' '--- remote v1.6.0 workflow ---'
cat -n "$tmp"
printf '%s\n' '--- relevant trigger, condition, and publish expressions ---'
rg -n -C 3 'on:|push:|pull_request:|workflow_dispatch|paths:|if:|tex|branch|publish|PR|pull_request' "$tmp"Repository: tschm/TinyCTA Length of output: 30248 Correct the trigger and publication-frequency claims. The workflow triggers on matching 🤖 Prompt for AI Agents |
||
|
|
||
| The PDF is published three ways, which is deliberate — they fail differently: | ||
|
|
||
| 1. **The run artifact**, named `paper`. Immediate, and it expires after 30 days. | ||
| 2. **The book.** `paper` is a prerequisite of `book` and this folder sits inside the | ||
| docs tree, so mkdocs sweeps the PDF up as a site asset at a stable URL. Link it | ||
| from the nav to make it reachable: | ||
|
|
||
| ```yaml | ||
| nav: | ||
| - Paper: paper/main.pdf | ||
| ``` | ||
|
|
||
| 3. **The `paper` branch**, which holds the compiled PDF and a generated `README.md` | ||
| explaining what the branch is — and nothing else. Pushed on every default-branch run, | ||
| never from a pull request. This is the copy you can link without building the site and | ||
| without an unexpired run. | ||
|
|
||
| The README is written by the workflow, so anything you commit there by hand is | ||
| overwritten on the next run. It deliberately carries no run number or timestamp: that | ||
| would make the file differ every time, and the branch would collect a commit per push | ||
| whether or not the paper changed. The source commit each PDF was built from is named in | ||
| the commit message instead. | ||
|
|
||
| For the same reason the compile pins `SOURCE_DATE_EPOCH` to the source commit's time. | ||
| tectonic otherwise stamps the PDF `/ID` from the build time, so an unchanged document | ||
| compiles to different bytes on every run — which would commit every time regardless of | ||
| the README. With it, a rebuild of a revision you have already published is a no-op. | ||
|
|
||
| Nothing needs to be tracked for this to work — the template gitignores | ||
| `docs/paper/*.pdf`. If you commit your PDF anyway, the publish still works; it discards | ||
| the freshly compiled copy from the working tree after staging it, which is the only way | ||
| to switch branches with a modified tracked file in the way. | ||
|
|
||
| The GitLab pipeline publishes the first two. It does not push the branch: that needs a | ||
| token `CI_JOB_TOKEN` cannot stand in for, and this template sets up no project secret. | ||
|
|
||
|
Comment on lines
+112
to
+114
There was a problem hiding this comment. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- docs/paper/README.md ---'
sed -n '100,120p' docs/paper/README.md
printf '%s\n' '--- repository references to CI_JOB_TOKEN and branch publishing ---'
rg -n -C 2 'CI_JOB_TOKEN|branch publish|publishes the first two|pipeline publishes' . --glob '!node_modules' --glob '!dist' --glob '!build' || trueRepository: tschm/TinyCTA Length of output: 2299 🌐 Web query:
💡 Result: The ability to use the CI_JOB_TOKEN to perform Git push requests to your project repository was generally available starting in GitLab 18.4 [1]. Key details regarding this functionality: - Default Setting: This setting is disabled by default [1][2][3]. - Implementation: It was originally introduced in GitLab 17.2 behind the feature flag allow_push_repository_for_job_token [1][4]. In GitLab 18.4, this feature flag was removed, marking the feature as generally available [1]. - Configuration: You can enable it by navigating to your project, selecting Settings > CI/CD, expanding Job token permissions, and selecting Allow Git push requests to the repository [1][2][3]. It can also be controlled via the ci_push_repository_for_job_token_allowed parameter in the projects API [1][2]. - Security/Functionality Note: When enabled, only job tokens generated by CI/CD jobs running in that project's pipelines can push to the project [1][2]. Importantly, no CI/CD pipelines are triggered when a push is performed using the job token [1][2]. Users are advised not to enable this setting on projects configured as pull mirrors to avoid potential security risks [1][2][3]. Citations:
🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- paper-related files ---'
git ls-files | rg '(^|/)(\.gitlab|.*paper.*|README\.md$)' | head -200
printf '%s\n' '--- CI configuration and token usage ---'
rg -n -C 3 'gitlab|CI_JOB_TOKEN|GITLAB_TOKEN|PRIVATE_TOKEN|git push|push.*branch|branch.*push' . --glob '*.yml' --glob '*.yaml' --glob '*.md' --glob '*.sh' --glob '*.toml' --glob '*.json' || trueRepository: tschm/TinyCTA Length of output: 2048 🌐 Web query:
💡 Result: To allow Git push requests to your repository using the CI_JOB_TOKEN in GitLab, you must enable the specific setting in your project configuration. This feature is disabled by default for security reasons [1]. When enabled, the CI_JOB_TOKEN functions with the same access permissions as the user who triggered the pipeline job [1]. Pushes performed using this token do not trigger additional CI/CD pipelines in the target project [1]. To enable this setting via the GitLab UI: 1. Navigate to your project in GitLab [1]. 2. In the left sidebar, select Settings > CI/CD [1]. 3. Expand the Job token permissions section [1]. 4. Select the option labeled Allow Git push requests to the repository [1]. Alternatively, you can manage this configuration via the Projects API by using the ci_push_repository_for_job_token_allowed parameter [1]. Security Note: GitLab explicitly advises against enabling this setting on projects configured as pull mirrors, as it could allow an upstream repository owner to attempt to use a CI_JOB_TOKEN to push commits to your project [1]. Citations: Describe GitLab supports repository pushes with 🤖 Prompt for AI Agents |
||
| ### If your repository has a `paper/<topic>` branch | ||
|
|
||
| Then the branch publish cannot work, and the workflow says so instead of failing | ||
| obscurely. Git refs are paths: `refs/heads/paper` cannot exist while | ||
| `refs/heads/paper/overview` does — the most natural branch convention for the very | ||
| feature this bundle serves. A preflight step lists the colliding ref and fails with it | ||
| named; git's own error on that push names neither branch. | ||
|
|
||
| Your options, in the order most repositories want them: | ||
|
|
||
| 1. Rename the topic branch — `paper/overview` → `paper-overview`. | ||
| 2. Leave it, and take the other two copies. The compile and the artifact upload run | ||
| before the preflight, so the PDF is still attached to the failed run and still | ||
| published by the book. Only the branch step is red. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: tschm/TinyCTA
Length of output: 36285
🏁 Script executed:
Repository: tschm/TinyCTA
Length of output: 2472
🌐 Web query:
jebel-quant/rhiza v1.6.0 .github/workflows rhiza_benchmark.yml workflow_call secrets GH_PAT UV_EXTRA_INDEX_URL💡 Result:
In the jebel-quant/rhiza repository, the rhiza_benchmark.yml workflow file (located in.github/workflows/) is configured to support workflow_call triggers, allowing it to be reused by other workflows [1]. Within its workflow_call definition, it specifies two optional secrets: GH_PAT and UV_EXTRA_INDEX_URL [1]. The purpose of these secrets in the context of this workflow is as follows: GH_PAT: This is used to provide authentication for private packages [1]. It is passed to a custom action, jebel-quant/rhiza/.github/actions/configure-git-auth, which configures git credentials to allow the workflow to access private repositories or packages during the benchmark process [1][2]. UV_EXTRA_INDEX_URL: This secret is mapped to the environment variable of the same name during the benchmark execution step [1]. It is used by uv, a Python package installer and resolver, to specify an additional index URL from which to fetch packages [3]. This is particularly useful when the project needs to install private or internal dependencies hosted on a custom package index [4]. By including these in the workflow_call section, the repository allows caller workflows to securely inject these sensitive values without hardcoding them directly into the reusable benchmark workflow [1][5].
Citations:
UV_EXTRA_INDEX_URLvariable doesn't get used inuv 0.1.44 (d417daad7 2024-05-14)astral-sh/uv#3614🏁 Script executed:
Repository: tschm/TinyCTA
Length of output: 9456
🌐 Web query:
site:docs.github.com reusable workflows secrets inherit reference secret not explicitly defined workflow_call💡 Result:
In GitHub Actions, you can pass secrets to a reusable workflow without explicitly defining them in the workflow_call trigger by using the secrets: inherit keyword in the calling workflow [1][2]. When you use secrets: inherit, all secrets available to the caller workflow are automatically passed to the reusable workflow [1][2]. This allows the reusable workflow to access these secrets via the secrets context, even if they are not explicitly declared in the on.workflow_call.secrets section of the reusable workflow's configuration [1][2]. Key details regarding this approach: Implicit Access: Unlike the standard method of mapping secrets, which requires each secret to be defined in the reusable workflow's on.workflow_call block, the inherit keyword provides a bulk way to grant access [1][3]. Usage: In your caller workflow, you define the call to the reusable workflow using the secrets: inherit syntax [1][2]: jobs: call-workflow: uses: owner/repo/.github/workflows/reusable.yml@main secrets: inherit Error Handling: It is important to note that if you do not use inherit and instead attempt to pass secrets that are not explicitly defined in the reusable workflow's on.workflow_call block, GitHub will typically raise an error [3][4]. Using inherit circumvents the need for this explicit mapping [1][2]. Nested Workflows: If you are calling a nested reusable workflow, secrets that were inherited by the parent reusable workflow are not automatically passed down to the child; you must explicitly pass them again using the jobs.<job_id>.secrets syntax or use inherit again if applicable at that level [3][4].
Citations:
🏁 Script executed:
Repository: tschm/TinyCTA
Length of output: 9957
Restrict secret forwarding in the Rhiza callers.
secrets: inheritgrants each called workflow access to every secret available to the caller.GH_PATandUV_EXTRA_INDEX_URLinrhiza_benchmark.yml,rhiza_ci.yml, andrhiza_weekly.yml.secrets: inheritfromrhiza_scorecard.ymlandrhiza_paper.yml.rhiza_book.yml,rhiza_codeql.yml, andrhiza_marimo.yml, add the requiredworkflow_call.secretsdeclarations upstream first. Then replace inheritance with explicit mappings: both secrets for book and marimo, andGH_PATfor CodeQL.🧰 Tools
🪛 zizmor (1.29.0)
[warning] 23-23: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
📍 Affects 8 files
.github/workflows/rhiza_benchmark.yml#L23-L23(this comment).github/workflows/rhiza_book.yml#L32-L32.github/workflows/rhiza_ci.yml#L29-L29.github/workflows/rhiza_codeql.yml#L29-L29.github/workflows/rhiza_marimo.yml#L31-L31.github/workflows/rhiza_scorecard.yml#L39-L39.github/workflows/rhiza_weekly.yml#L31-L31.github/workflows/rhiza_paper.yml#L42-L43🤖 Prompt for AI Agents
Source: Linters/SAST tools