LH017 sources

Read on 30 September 2026 before the brief was fixed and before any repository in the frame was cloned or read. Each read is logged in data/read_log_phase1.csv with its UTC time, status, bytes and the SHA-256 of what was served. Copies were kept in scratch space only, not in the repository. Times are UTC. LH015's sources D1 to D19 (the installers' and Docker's documentation, read on 29 September 2026) are cited through LH015's brief and were not read again.

Literature (the bounded check)

Five web searches, from about 06:48 to 06:50 UTC, with these queries: (1) empirical study GitHub Actions workflows Python dependency installation lockfile "pip install" CI; (2) how often do CI workflows use lockfiles "uv sync" OR "poetry install" OR "npm ci" empirical study repositories; (3) PyPI downloads from CI GitHub Actions share of downloads caching study; (4) arXiv empirical study GitHub Actions dependency caching or "lock file" install steps Python projects workflows 2025; (5) GitHub Actions default environment variables CI always set to true docs. A search result is a lead; only what is listed here as opened was read.

#	Source	Published	Read	What was taken from it
L1	Andrew Nesbitt, "GitHub Actions security in Python packages": https://nesbitt.io/2026/05/25/github-actions-security-in-python-packages.html	25 May 2026; its scan ran 9 to 11 May 2026	06:50:11	Of about 387,000 PyPI packages declaring a GitHub repository (343,000 distinct repositories), 152,000 have something in `.github/workflows/`; Travis CI accounts for 11 per cent of the same population and every other CI system below 2 per cent; astral-sh/setup-uv appears in about 17,000 repositories. It audits workflow security with zizmor and inventories `uses:` lines; it does not measure what install steps read.
L2	Hasan, Tian, Hassan and Ding, "How Developers Adopt, Use, and Evolve CI/CD Caching: An Empirical Study on GitHub Actions", arXiv 2604.13129: https://arxiv.org/abs/2604.13129	submitted 13 April 2026 (v1)	abstract 07:01:31	952 repositories, 266 of them adopting caching in GitHub workflows and 686 not; caching is used across job types through several mechanisms. The abstract does not say how the repositories were drawn or measure what install steps read.
L3	Rostami Mazrae, Decan, Mens and Wessel, "An Empirical Study of the Evolution of GitHub Actions Workflows", arXiv 2602.14572: https://arxiv.org/abs/2602.14572	submitted 16 February 2026 (v1)	abstract 07:01:31	Over 49,000 repositories, a median of three workflow files per repository; most changes concern task configuration and specification. No measure of install steps in the abstract.

Not opened: GitHub issues in two unrelated repositories on hardening CI installs, a DEV Community post, Michael Currin's code cookbook, two Medium posts on caching and on Poetry and uv lockfile strategies, a Towards Dev post, starsling.dev, a GitHub repository of reusable workflows, the Instructor blog, DZone, latchkey.dev, pratikpathak.com, AI2's blog on Python caching, proxpi, Simon Willison's note on setup-python caching, testmon's blog, adhdecode.com, oneuptime.com's two posts, hypertest.co, GitHub's changelog of 15 April 2020 on the CI variable (the variables reference G1 was read instead), arXiv 2507.18062 on the complexity of GitHub Actions workflows, arXiv 2305.16120 on workflows and security policies, and the setup-python repository's page on github.com (its README was read from raw.githubusercontent.com, A1). No published measure of how often a Python project's CI installs from its own lockfile was found in five searches, which says little about whether one exists. What it changed: nothing in the design beyond S2's cache reading, which L2's split of adopters and non-adopters makes worth recording as written, since a cached job may fetch nothing from the index.

Documentation

#	Source	Read	What was taken from it
G1	GitHub Docs, variables reference: https://docs.github.com/en/actions/reference/workflows-and-actions/variables	06:50:50	"CI Always set to true. You can use this variable to differentiate when tests are being run locally or by GitHub Actions."
G2	GitHub Docs, workflow syntax: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax	06:50:51	Workflow files use YAML, "must have either a .yml or .yaml file extension", and must be stored in the `.github/workflows` directory; a step's `working-directory`, and `defaults.run` for "default shell and working-directory options for all run steps in a workflow" or a job, where "GitHub uses the most specific default" and no expression is allowed; matrix `include` adds keys to each combination unless they overwrite an original value, else makes a new combination, and "All include combinations are processed after exclude"; `jobs.<job_id>.uses` names a reusable workflow in the same repository (`./.github/workflows/{filename}`) or another (`{owner}/{repo}/.github/workflows/{filename}@{ref}`); a job may run in a `container`.
G3	GitHub Docs, metadata syntax for actions: https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax	06:50:51	An action's metadata file is `action.yml` or `action.yaml`; a composite action's `runs` lists steps.
G4	GitHub Docs, building and testing Python: https://docs.github.com/en/actions/tutorials/build-and-test-code/python	06:50:52	GitHub's own tutorial of installing dependencies in a workflow (setup-python with caching, `pip install -r requirements.txt`); context only.
G5	GitLab CI/CD YAML reference: https://docs.gitlab.com/ci/yaml/	06:50:52	Jobs, `script`, `before_script`, `default`, `extends`, `include:local`, `parallel:matrix`.
G6	GitLab predefined variables: https://docs.gitlab.com/ci/variables/predefined_variables/	06:50:52	"CI ... Available for all jobs executed in CI/CD. true when available."
T1	tox configuration reference: https://tox.wiki/en/latest/reference/config.html (the old address https://tox.wiki/en/latest/config.html, read at 06:51:21, redirects to it)	06:51:32	`deps` are pip requirement lines, including `-r requirements.txt` and `-c constraints.txt`; `constraints` files apply to package and dependency installation (from 4.28.0); `skip_install`: "Skip installation of the package"; `package` is one of wheel, sdist, sdist-wheel, editable, editable-legacy, deps-only, skip or external, becoming editable with `use_develop` and skip with `skip_install`; `deps-only` installs the package's dependencies, including extras, without the package; `use_develop` installs the package in development mode; factor-conditional settings.
T2	tox-uv on PyPI's JSON API (version 1.36.0, uploaded 21 July 2026): https://pypi.org/pypi/tox-uv/json	06:51:22	`uv-venv-lock-runner` is the runner "for environments using `uv.lock`"; it uses `uv sync`, and "when using `uv-venv-lock-runner`, all dependencies will come from the lock file, controlled by `extras`. Therefore, options like `deps` are ignored".
N1	nox configuration and API: https://nox.thea.codes/en/stable/config.html	06:51:22	`session.install` "invokes pip to install packages inside of the session's virtualenv", with `session.install('-r', 'requirements.txt')` and `session.install('.')` as its examples; `session.run_install` runs "a command in the install step"; `session.conda_install` invokes conda install; the uv backend does not reinstall.
N2	nox usage: https://nox.thea.codes/en/stable/usage.html	06:51:22	Selecting sessions with `-s`; default sessions.
H1	Hatch, environment configuration: https://hatch.pypa.io/latest/config/environment/overview/	06:51:23	Environments install the project in editable (development) mode unless `dev-mode = false`, and install it on creation unless `skip-install = true`; "Hatch can generate PEP 751 lockfiles (`pylock.toml`) for environments" when `locked = true`, and the built-in pip locker "does not currently implement apply_lock".
H2	Hatch, internal testing environment: https://hatch.pypa.io/latest/config/internal/testing/	06:51:23	`hatch test` runs in the internal environment `hatch-test`, configured under `[tool.hatch.envs.hatch-test]`; as an environment it installs as H1 says.
A1	actions/setup-python README: https://raw.githubusercontent.com/actions/setup-python/main/README.md, and A1b, its advanced usage: https://raw.githubusercontent.com/actions/setup-python/main/docs/advanced-usage.md	06:51:24	The action installs a Python "and (by default) adding it to the PATH", "Optionally caching dependencies for pip, pipenv and poetry"; `cache-dependency-path` names the files whose hash keys the cache. It installs no project requirements.
A2	astral-sh/setup-uv README: https://raw.githubusercontent.com/astral-sh/setup-uv/main/README.md	06:51:24	Installs uv; `enable-cache` defaults to "auto" (disabled on self-hosted runners, by its comment); `activate-environment` creates a virtual environment with `uv venv`; no project install.
A3	snok/install-poetry README: https://raw.githubusercontent.com/snok/install-poetry/main/README.md	06:51:24	"A Github action for installing and configuring Poetry"; project installs are separate `poetry install` steps.
A4	pdm-project/setup-pdm README: https://raw.githubusercontent.com/pdm-project/setup-pdm/main/README.md	06:51:25	Sets up PDM; dependencies are installed by a separate `run: pdm install` step.
A5	conda-incubator/setup-miniconda README: https://raw.githubusercontent.com/conda-incubator/setup-miniconda/main/README.md	06:51:25	Can create an environment "described in a given `environment-file`", an `environment.yml`-like file or a lockfile.
A6	mamba-org/setup-micromamba README: https://raw.githubusercontent.com/mamba-org/setup-micromamba/main/README.md	06:51:25	`environment-file: environment.yml` creates the environment from that file.
U1	uv, using uv in GitHub Actions: https://docs.astral.sh/uv/guides/integration/github/	06:51:25	The guide's install step is `uv sync --locked --all-extras --dev`, then `uv run pytest tests`.
P1	pre-commit: https://pre-commit.com/	06:51:26	For Python hooks, "The hook repository must be installable via pip install ."; hooks are installed into their own environments.
D1	Docker Docs, build variables: https://docs.docker.com/build/building/variables/	06:51:26	Build arguments and environment variables are "both declared in the Dockerfile and can be set using flags for the docker build command". The page was searched for these passages, not read whole.

Read after the brief

Documentation read by the writer after workflows were seen, each logged in data/read_log.csv with its time and size; ten pages in eleven attempts, the brief's ceiling. Copies were kept in scratch space only.

Source	Read	For	What was taken from it
hatch-pip-compile on PyPI's JSON API: https://pypi.org/pypi/hatch-pip-compile/json	07:32:35	reading B1	Its environments install from the lockfiles the plugin writes.
Poetry's commands: https://python-poetry.org/docs/cli/	07:32:46 (a first attempt at 07:32:05 failed)	amendment 2	On `poetry add` and `poetry update`, `--lock`: "Do not perform install (only update the lockfile)".
uv, workspaces: https://docs.astral.sh/uv/concepts/projects/workspaces/	08:45:44, after amendment 3 was made	amendment 3	A workspace "shares a single lockfile"; `uv run` and `uv sync` "operate on the workspace root by default, though both accept a --package argument"; members are the directories the `members` globs include and the `exclude` globs do not.
setup-uv's README at main (v10.1.0): https://raw.githubusercontent.com/astral-sh/setup-uv/main/README.md	09:11:04, after the counts	Finding 15	`enable-cache` "auto" (on for GitHub-hosted runners, except some events); `prune-cache` "false".
uv, caching: https://docs.astral.sh/uv/concepts/cache/	09:11:04, after the counts	Finding 15	`uv cache prune --ci` "removes all pre-built wheels and unzipped source distributions from the cache, but retains any wheels that were built from source".
setup-uv's caching guide at main: https://raw.githubusercontent.com/astral-sh/setup-uv/main/docs/caching.md	09:11:23, after the counts	Finding 15	"By default, the entire uv cache is persisted across runs"; pruning, when enabled, removes pre-built wheels, which "are then re-downloaded from the registry on each run".
setup-uv's README at v6: https://raw.githubusercontent.com/astral-sh/setup-uv/v6/README.md	09:11:41, after the counts	Finding 15	"Caching is enabled by default on GitHub-hosted runners"; "By default, the uv cache is pruned after every run, removing pre-built wheels".
setup-uv's README at v5: https://raw.githubusercontent.com/astral-sh/setup-uv/v5/README.md	09:11:42, after the counts	Finding 15	The same two statements as at v6.
setup-uv's README at v4: https://raw.githubusercontent.com/astral-sh/setup-uv/v4/README.md	09:12:30, after the counts	Finding 15	Caching as something the workflow enables, with no default stated; "By default, the uv cache is pruned after every run".
setup-uv's README at v7: https://raw.githubusercontent.com/astral-sh/setup-uv/v7/README.md	09:12:31, after the counts	Finding 15	`enable-cache` "auto" (on for GitHub-hosted runners); `prune-cache` "true".