gc-batch 0.2.0__tar.gz

gc_batch-0.2.0/.gitignore

@@ -0,0 +1,53 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+
+# Environments
+.env
+.venv
+.venv-licenses
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+#python
+*.egg-info/
+*.egg-info/*
+
+# uv specific
+.uv/
+
+# macOS
+.DS_Store
+
+# Temporary folders
+tmp/
+temp/
+
+# Editor directories and files
+.vscode/
+!.vscode/extensions.json
+.idea
+
+# Secrets
+*.secret.env
+
+# Version files
+*_version.py
+
+dist/
+
+# Local git worktrees
+.worktrees/
+
+# mkdocs build output
+site/
+
+# Claude Code local settings
+.claude/

gc_batch-0.2.0/CHANGELOG.md

@@ -0,0 +1,100 @@
+# Changelog
+
+All notable changes to this project are documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [0.2.0]
+
+First public release.
+
+### Added
+
+- CLI for managing Google Cloud Batch jobs: `create`, `list-jobs`, `list-my-jobs`,
+  `status`, `logs`, `cancel`, and `show-config`.
+- `gc-batch --version`, which the contributing and security guides ask bug
+  reporters to include.
+- `GCBatchClient`, a Python client for the same operations, and
+  `BatchJobConfig.apply_profile`, which applies a `JobProfile`'s networking and VM
+  settings to a job config — what `create --job-profile` does under the hood, also
+  reachable directly from library code.
+- GCS bucket mounts for job input, output, and logs, and local SSD storage.
+- Automatic `job-name`, `created-using`, `created-at`, and `created-by` labels, plus
+  filtering by label, name, status, and time window. The `created-by` label is set
+  by `GCBatchClient.create_job`, so jobs submitted through the Python client carry
+  it too and are found by `list-my-jobs`; a `created-by` passed in
+  `JobRequest.labels` takes precedence over the environment-derived value.
+  `owner_email_env_vars` defaults to
+  `["OWNER_EMAIL", "WORKBENCH_USER_EMAIL", "TERRA_USER_EMAIL", "USER"]`, so
+  `created-by` (and therefore `list-my-jobs`) works inside the All of Us Researcher
+  Workbench, which sets the first three but not `$USER`; `$USER` remains the final
+  fallback elsewhere.
+- `GCBatchSettings` (`gc_batch.settings`), resolving configuration from constructor
+  arguments, `GC_BATCH_*` environment variables, a TOML config file, and neutral
+  defaults, in that precedence order.
+- Named job profiles via `--job-profile`, including a built-in `all-of-us` profile
+  for the restricted-VPC All of Us Researcher Workbench environment. `create` warns
+  when a job profile declares that Cloud Logging is unreadable and no
+  `--logs-bucket` was given — the case where a job's logs are written somewhere the
+  user cannot read them. The log destination is fixed when the job is created, so
+  the warning names the only remedy: recreate with `--logs-bucket`. The `all-of-us`
+  profile sets this `cloud_logging_unreadable` flag; it defaults to false, so
+  nothing changes for other profiles. The warning goes to stderr and does not block
+  job creation, and the `Cloud Logging URL` line that `create` prints on success is
+  annotated in the same case, since that URL will show nothing.
+- Logs written to a GCS bucket are readable. `gc-batch logs print` and
+  `logs download` detect that a job was created with `--logs-bucket` and read the
+  log objects out of the bucket instead of querying Cloud Logging. That is the only
+  working log route where the caller has no Cloud Logging read access at all — for
+  example the All of Us Researcher Workbench, where the workspace pet service
+  account gets `403 Permission denied for all log views`. The bucket and per-job
+  prefix are recovered from the job resource, so nothing extra has to be passed.
+  Logs written with `--logs-bucket` land in a per-job subfolder beneath the given
+  path, `gs://<logs-bucket-path>/<generated-job-name>/`; the path printed by
+  `create` is the parent folder, not the one holding that job's files.
+- `GCSLogReader` (`gc_batch.gcs_logging`) for reading those logs from Python. It
+  returns entries in the same shape as the Cloud Logging reader, preserves the
+  order Batch wrote them in, reads whole objects (no result cap, so long logs are
+  not silently truncated), decodes lossily so a job printing binary output cannot
+  break log retrieval, and honours a requester-pays billing project recorded on the
+  job. Logs read from a `--logs-bucket` job preserve output order: the interleaved
+  `output-` object is read instead of separate per-stream objects, so stderr lines
+  emitted mid-run keep their original position, and the Batch agent's own lines are
+  dropped by stream tag.
+- `gc-batch logs print` and `logs download` exit 1 when log retrieval fails, so a
+  wrapper script can tell a 403 from a job that simply produced no output; a
+  successful read of zero entries exits 0 and reports `No log entries matched the
+  query`. For the same reason `BatchLogging._query_cloud_logs`, `print_logs_for_job`,
+  and `download_logs_for_job` raise on API errors rather than swallowing them, and
+  the two public methods return the number of entries handled;
+  `get_instance_id_from_logs` returns `None` when its query fails. An unrecognised
+  `--severity` value is rejected with a clear error when reading logs from a
+  bucket, instead of silently matching nothing.
+- `gc-batch status` on a job that logs to a bucket points at the bucket instead of
+  offering a Cloud Logging console URL with nothing behind it, and `logs filter` /
+  `logs url` say plainly that their Cloud Logging query will match nothing for such
+  a job. `gc-batch status` on a failed job that produced no logs at all adds a
+  clearly labelled inference that the container never started and the image
+  probably could not be pulled, naming the image URI. The Batch API never states
+  this reason — the only failure text is "… with exit code 1" — so it is presented
+  as an inference, not as something Batch reported.
+- `LICENSE` (MIT), `CONTRIBUTING.md`, `SECURITY.md`, and this changelog.
+- CI running `ruff`, `mypy` (blocking), `pytest`, and a strict docs build across
+  Python 3.10-3.13.
+
+### Documentation
+
+- Documentation for using gc-batch as a Python library: a [Python API
+  guide](docs/guides/python-api.md) covering submission, polling, filtering, logs,
+  mounts, settings, job profiles, fan-out, and error handling, plus library
+  examples in the README and alongside the CLI example workflows.
+- Troubleshooting covers the two ways log retrieval comes up empty: a job that
+  failed before its container started (no task logs and no GCS objects are written,
+  and the Batch API never states the reason), and `403 Permission denied for all log
+  views`, which is the normal state in restricted environments and is solved by
+  creating jobs with `--logs-bucket`. Includes how to tell an unreachable registry
+  from a bad image reference, the `/bin/bash` entrypoint requirement, and the
+  per-task log object naming.

gc_batch-0.2.0/CONTRIBUTING.md

@@ -0,0 +1,144 @@
+# Contributing to gc-batch
+
+Thanks for your interest in contributing. This document covers how to get set up,
+what the review expectations are, and how to propose changes. Participation in
+this project is governed by our [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Getting set up
+
+`gc-batch` uses [uv](https://docs.astral.sh/uv/) for dependency and environment
+management, and [just](https://github.com/casey/just) as a task runner.
+
+```bash
+git clone https://github.com/empirico-oss/gc-batch.git
+cd gc-batch
+uv sync
+```
+
+Supported Python versions are 3.10 through 3.13.
+
+## Development workflow
+
+```bash
+just test          # run the test suite
+just lint          # ruff check, ruff format --check, mypy
+just preview-docs  # serve the documentation locally
+```
+
+Before opening a pull request, make sure all of the following pass, since CI runs
+the same checks:
+
+```bash
+uv run pytest -vv tests
+uv run ruff check .
+uv run ruff format --check .
+uv run mypy src
+uv run --group docs mkdocs build --strict
+```
+
+These map to the jobs in `.github/workflows/ci.yaml`, which runs on every pull
+request and on pushes to `main`: `lint` (ruff), `types` (mypy, blocking), `test`
+(pytest on Python 3.10-3.13), `licenses` (runtime dependency licenses stay
+MIT-compatible -- `just licenses`), and `docs` (`mkdocs build --strict`, so a
+broken link or reference fails the build).
+
+## Building and installing
+
+Released versions are published to [PyPI](https://pypi.org/project/gc-batch/)
+and install with `pip install gc-batch`. To test unreleased changes -- or before
+the first release lands -- build a wheel locally:
+
+```bash
+uv build            # writes dist/gc_batch-<version>-{py3-none-any.whl,.tar.gz}
+```
+
+Then install it one of three ways:
+
+```bash
+pip install dist/gc_batch-<version>-py3-none-any.whl          # built wheel
+uv tool install --force --no-cache ./                          # local checkout
+pip install "gc-batch @ git+https://github.com/empirico-oss/gc-batch.git@main"
+```
+
+Re-running the `uv tool install` line with `--force` is also how you update an
+existing global install. Verify with `gc-batch --version`.
+
+Documentation is published by `.github/workflows/mkdocs.yaml`, which tracks
+releases rather than pushes to `main` -- see
+[Deploying Documentation](docs/development/docs.md#deploying-documentation). The
+`docs` CI job builds the site with `--strict` on every pull request.
+
+## Releasing
+
+`.github/workflows/release.yaml` publishes to PyPI when a GitHub Release is
+published. It builds the sdist and wheel, verifies them, and uploads via PyPI
+Trusted Publishing, so no API token is stored in the repository.
+
+The release tag is the source of truth for the version: `uv-dynamic-versioning`
+derives the version from git, and the workflow refuses to publish if the built
+version does not match the tag. To cut a release:
+
+1. Move the pending `CHANGELOG.md` entries under a new version heading.
+2. Publish a GitHub Release tagged `v<version>` (for example `v0.1.0`).
+3. Approve the `pypi` environment if it is configured to require review.
+
+Dispatch the same workflow manually to publish to TestPyPI first. Run it from a
+tag ref, not a branch: off-tag builds carry PEP 440 local version metadata
+(`+branch.sha`), which no package index accepts.
+
+Releasing also deploys documentation for that version. The two workflows trigger
+deliberately differently -- the release workflow runs for any published release
+*including* pre-releases, while the docs workflow runs only for full releases --
+so a release candidate reaches PyPI without moving the `stable` docs alias.
+
+## Code standards
+
+- **Type hints are required** on public functions and methods. `mypy` runs over
+  `src/` in CI.
+- **Formatting and linting** are handled by `ruff` (line length 100). Run
+  `uv run ruff format .` to apply formatting.
+- **Docstrings** follow the Google style, since the API documentation is generated
+  from them by `mkdocstrings`.
+- **No deployment-specific values in source.** Project IDs and network
+  configuration belong in settings (see below), never hardcoded. This is
+  enforced by review.
+
+## Configuration, not hardcoding
+
+Anything that differs between deployments is resolved through `GCBatchSettings`
+in `src/gc_batch/settings.py`, with precedence:
+
+1. explicit constructor argument
+2. `GC_BATCH_*` environment variables
+3. a TOML config file (`--config-file`, `$GC_BATCH_CONFIG_FILE`, `./gc-batch.toml`,
+   or `$XDG_CONFIG_HOME/gc-batch/config.toml`)
+4. neutral defaults in code
+
+If you are adding a value that varies by environment, add it as a settings field
+with a sensible neutral default rather than a literal in the code path. See
+[Configuration](docs/guides/configuration.md).
+
+## Tests
+
+- New logic needs tests. Bug fixes should include a test that fails before the fix.
+- Tests live in `tests/` and mirror the `src/gc_batch/` layout.
+- Avoid tests that require live Google Cloud credentials; mock the client
+  boundaries as the existing tests do.
+
+## Pull requests
+
+- Keep pull requests focused on a single concern.
+- Describe the motivation, not just the change.
+- Call out any breaking change to the CLI surface or the public Python API
+  explicitly in the description, and update `CHANGELOG.md`.
+- Update the relevant documentation under `docs/` in the same pull request.
+
+## Reporting bugs and requesting features
+
+Open an issue at https://github.com/empirico-oss/gc-batch/issues. For bugs, please include
+the `gc-batch` version, your Python version, the command you ran, and the full
+error output. Do not include credentials, access tokens, internal project
+identifiers, or participant data in issue reports.
+
+For security issues, follow [SECURITY.md](SECURITY.md) instead of opening a
+public issue.

gc_batch-0.2.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Empirico Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

gc_batch-0.2.0/PKG-INFO

@@ -0,0 +1,182 @@
+Metadata-Version: 2.5
+Name: gc-batch
+Version: 0.2.0
+Summary: Command-line interface and Python client for managing Google Cloud Batch jobs
+Project-URL: Homepage, https://github.com/empirico-oss/gc-batch
+Project-URL: Documentation, https://empirico-oss.github.io/gc-batch/stable/
+Project-URL: Repository, https://github.com/empirico-oss/gc-batch
+Project-URL: Issues, https://github.com/empirico-oss/gc-batch/issues
+Project-URL: Changelog, https://github.com/empirico-oss/gc-batch/blob/main/CHANGELOG.md
+Author: Empirico Inc.
+License-Expression: MIT
+License-File: LICENSE
+Keywords: batch,bioinformatics,cli,google-cloud,google-cloud-batch
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Intended Audience :: Science/Research
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: System :: Distributed Computing
+Classifier: Typing :: Typed
+Requires-Python: <3.14.0,>=3.10.0
+Requires-Dist: click>=8.2.1
+Requires-Dist: google-cloud-batch>=0.17.36
+Requires-Dist: google-cloud-logging>=3.12.1
+Requires-Dist: google-cloud-storage>=3.2.0
+Requires-Dist: pydantic-settings>=2.7.0
+Requires-Dist: pydantic>=2.12.0
+Description-Content-Type: text/markdown
+
+# gc-batch
+
+A command-line interface and Python client for managing Google Cloud Batch jobs,
+with support for job creation, monitoring, logging, GCS bucket mounts, local SSD
+storage, and filtering by labels.
+
+## Installation
+
+```bash
+pip install gc-batch
+```
+
+Or, for development, using [uv](https://docs.astral.sh/uv/):
+
+```bash
+git clone https://github.com/empirico-oss/gc-batch.git
+cd gc-batch
+uv sync
+```
+
+Requires Python 3.10 or newer, and credentials for a Google Cloud project with the
+Batch API enabled (`gcloud auth application-default login`).
+
+## Quick start
+
+```bash
+# Create a job
+gc-batch --project-id my-project create \
+  --job-name my-first-job \
+  --docker-image gcr.io/my-project/my-image:latest \
+  --command "python /app/main.py"
+
+# List jobs, or just your own
+gc-batch --project-id my-project list-jobs
+gc-batch --project-id my-project list-my-jobs
+
+# Check status and read logs
+gc-batch --project-id my-project status --job-name my-first-job-1234567890
+gc-batch --project-id my-project logs --job-name my-first-job-1234567890
+```
+
+The project is resolved from `--project-id`, then `$GOOGLE_PROJECT`, then the
+`default_project_id` setting. If none is set, the command exits with an error
+rather than guessing.
+
+## Use as a Python library
+
+The same functionality is importable, so scripts, notebooks, and orchestration
+code can submit and monitor jobs without shelling out to the CLI:
+
+```python
+import time
+
+from gc_batch import BatchClientConfig, BatchJobConfig, GCBatchClient, JobRequest
+from gc_batch.utils import is_job_finished
+
+client = GCBatchClient(BatchClientConfig(project_id="my-project", location="us-central1"))
+
+job = client.create_job(
+    JobRequest(
+        job_name="my-first-job",
+        docker_image="gcr.io/my-project/my-image:latest",
+        command="python /app/main.py",
+        config=BatchJobConfig(
+            machine_type="n2-standard-4",
+            boot_disk_type="pd-balanced",
+            input_bucket="my-bucket/datasets",
+            output_bucket="my-bucket/results",
+        ),
+        labels={"team": "data-science"},
+    )
+)
+
+# create_job timestamps the name, so read the submitted one off the job
+short_name = job.name.split("/")[-1]
+
+while not is_job_finished(job := client.get_job(short_name)):
+    time.sleep(30)
+
+print(job.status.state.name)
+if job.status.state.name == "FAILED":
+    print(client.get_failure_message(job))
+    print(client.get_cloud_logging_url(job, severity="ERROR"))
+```
+
+Listing, cancelling, and log retrieval are all available too:
+
+```python
+jobs = client.list_jobs(labels={"team": "data-science"}, status="RUNNING")
+client.cancel_job(job.name)  # full resource path, not the short name
+
+# Logs, from Cloud Logging or from the bucket when the job used logs_bucket
+client.batch_logging.print_logs_for_job(job)
+client.gcs_logging.print_logs_for_job(job)
+```
+
+See the [Python API guide](docs/guides/python-api.md) for job profiles, mounts,
+local SSD, settings, fan-out, and error handling.
+
+## Configuration
+
+Values that differ between deployments — the job-name prefix, the
+`created-using` label, and named job profiles — are resolved in this order,
+highest precedence first:
+
+1. explicit arguments
+2. `GC_BATCH_*` environment variables
+3. a TOML config file (`--config-file`, `$GC_BATCH_CONFIG_FILE`, `./gc-batch.toml`,
+   or `$XDG_CONFIG_HOME/gc-batch/config.toml`)
+4. neutral defaults
+
+### Restricted VPC environments
+
+`gc-batch` ships a built-in `all-of-us` job profile for the
+[All of Us](https://allofus.nih.gov/) Researcher Workbench, which runs jobs inside
+a restricted VPC:
+
+```bash
+gc-batch --project-id my-project create \
+  --job-profile all-of-us \
+  --job-name my-job \
+  --docker-image gcr.io/my-project/my-image:latest \
+  --command "python /app/main.py"
+```
+
+You can define additional profiles in the config file. See the
+[Configuration guide](docs/guides/configuration.md).
+
+## Documentation
+
+Full documentation: https://empirico-oss.github.io/gc-batch/stable/
+
+- [Quick Start](docs/guides/quick-start.md)
+- [Commands Reference](docs/guides/commands.md)
+- [Python API](docs/guides/python-api.md)
+- [Input/Output Mounts](docs/guides/mounts.md)
+- [Local SSD Storage](docs/guides/local-ssd.md)
+- [Label Management](docs/guides/labels.md)
+- [Configuration](docs/guides/configuration.md)
+- [Troubleshooting](docs/guides/troubleshooting.md)
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md). Security issues should be reported per
+[SECURITY.md](SECURITY.md).
+
+## License
+
+MIT — see [LICENSE](LICENSE).

gc_batch-0.2.0/README.md

@@ -0,0 +1,149 @@
+# gc-batch
+
+A command-line interface and Python client for managing Google Cloud Batch jobs,
+with support for job creation, monitoring, logging, GCS bucket mounts, local SSD
+storage, and filtering by labels.
+
+## Installation
+
+```bash
+pip install gc-batch
+```
+
+Or, for development, using [uv](https://docs.astral.sh/uv/):
+
+```bash
+git clone https://github.com/empirico-oss/gc-batch.git
+cd gc-batch
+uv sync
+```
+
+Requires Python 3.10 or newer, and credentials for a Google Cloud project with the
+Batch API enabled (`gcloud auth application-default login`).
+
+## Quick start
+
+```bash
+# Create a job
+gc-batch --project-id my-project create \
+  --job-name my-first-job \
+  --docker-image gcr.io/my-project/my-image:latest \
+  --command "python /app/main.py"
+
+# List jobs, or just your own
+gc-batch --project-id my-project list-jobs
+gc-batch --project-id my-project list-my-jobs
+
+# Check status and read logs
+gc-batch --project-id my-project status --job-name my-first-job-1234567890
+gc-batch --project-id my-project logs --job-name my-first-job-1234567890
+```
+
+The project is resolved from `--project-id`, then `$GOOGLE_PROJECT`, then the
+`default_project_id` setting. If none is set, the command exits with an error
+rather than guessing.
+
+## Use as a Python library
+
+The same functionality is importable, so scripts, notebooks, and orchestration
+code can submit and monitor jobs without shelling out to the CLI:
+
+```python
+import time
+
+from gc_batch import BatchClientConfig, BatchJobConfig, GCBatchClient, JobRequest
+from gc_batch.utils import is_job_finished
+
+client = GCBatchClient(BatchClientConfig(project_id="my-project", location="us-central1"))
+
+job = client.create_job(
+    JobRequest(
+        job_name="my-first-job",
+        docker_image="gcr.io/my-project/my-image:latest",
+        command="python /app/main.py",
+        config=BatchJobConfig(
+            machine_type="n2-standard-4",
+            boot_disk_type="pd-balanced",
+            input_bucket="my-bucket/datasets",
+            output_bucket="my-bucket/results",
+        ),
+        labels={"team": "data-science"},
+    )
+)
+
+# create_job timestamps the name, so read the submitted one off the job
+short_name = job.name.split("/")[-1]
+
+while not is_job_finished(job := client.get_job(short_name)):
+    time.sleep(30)
+
+print(job.status.state.name)
+if job.status.state.name == "FAILED":
+    print(client.get_failure_message(job))
+    print(client.get_cloud_logging_url(job, severity="ERROR"))
+```
+
+Listing, cancelling, and log retrieval are all available too:
+
+```python
+jobs = client.list_jobs(labels={"team": "data-science"}, status="RUNNING")
+client.cancel_job(job.name)  # full resource path, not the short name
+
+# Logs, from Cloud Logging or from the bucket when the job used logs_bucket
+client.batch_logging.print_logs_for_job(job)
+client.gcs_logging.print_logs_for_job(job)
+```
+
+See the [Python API guide](docs/guides/python-api.md) for job profiles, mounts,
+local SSD, settings, fan-out, and error handling.
+
+## Configuration
+
+Values that differ between deployments — the job-name prefix, the
+`created-using` label, and named job profiles — are resolved in this order,
+highest precedence first:
+
+1. explicit arguments
+2. `GC_BATCH_*` environment variables
+3. a TOML config file (`--config-file`, `$GC_BATCH_CONFIG_FILE`, `./gc-batch.toml`,
+   or `$XDG_CONFIG_HOME/gc-batch/config.toml`)
+4. neutral defaults
+
+### Restricted VPC environments
+
+`gc-batch` ships a built-in `all-of-us` job profile for the
+[All of Us](https://allofus.nih.gov/) Researcher Workbench, which runs jobs inside
+a restricted VPC:
+
+```bash
+gc-batch --project-id my-project create \
+  --job-profile all-of-us \
+  --job-name my-job \
+  --docker-image gcr.io/my-project/my-image:latest \
+  --command "python /app/main.py"
+```
+
+You can define additional profiles in the config file. See the
+[Configuration guide](docs/guides/configuration.md).
+
+## Documentation
+
+Full documentation: https://empirico-oss.github.io/gc-batch/stable/
+
+- [Quick Start](docs/guides/quick-start.md)
+- [Commands Reference](docs/guides/commands.md)
+- [Python API](docs/guides/python-api.md)
+- [Input/Output Mounts](docs/guides/mounts.md)
+- [Local SSD Storage](docs/guides/local-ssd.md)
+- [Label Management](docs/guides/labels.md)
+- [Configuration](docs/guides/configuration.md)
+- [Troubleshooting](docs/guides/troubleshooting.md)
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md). Security issues should be reported per
+[SECURITY.md](SECURITY.md).
+
+## License
+
+MIT — see [LICENSE](LICENSE).