TEST-INFRA: [ci-pipeline-design] Improve dependency caching #1797

New issue

Open

opened 2026-04-02 23:52:04 +00:00 by freemo · 1 comment

freemo commented

2026-04-02 23:52:04 +00:00

Owner

Metadata

Branch: chore/ci-improve-dependency-caching
Commit Message: chore(ci): include uv.lock in cache key for deterministic dependency caching
Milestone: v3.8.0
Parent Epic: #1678

Background and Context

The current dependency caching in ci.yml uses a cache key based on pyproject.toml. While this is a good starting point, it does not guarantee that the exact same resolved dependency set is used on every CI run. The uv.lock file is the authoritative record of the fully-resolved, pinned dependency graph. If uv.lock changes (e.g., a transitive dependency is updated) without pyproject.toml changing, the cache will not be invalidated and stale dependencies may be used.

Expected Behavior

The cache key in ci.yml should include a hash of the uv.lock file so that any change to the resolved dependency graph — whether direct or transitive — triggers a fresh cache population.

Acceptance Criteria

The cache key in .forgejo/workflows/ci.yml includes a hash of uv.lock in addition to (or instead of) pyproject.toml.
A change to uv.lock alone causes the cache to be invalidated on the next CI run.
The CI pipeline continues to pass with the updated cache key.

Subtasks

Update the cache key in .forgejo/workflows/ci.yml to include hashFiles('uv.lock') (alongside or replacing the existing pyproject.toml hash)
Verify the updated cache key is syntactically valid in the Forgejo/GitHub Actions workflow format
Update features/ci_workflow_validation.feature to assert the cache key includes uv.lock
Run nox (all default sessions) and fix any errors
Verify coverage >= 97% via nox -s coverage_report

Definition of Done

This issue is complete when:

All subtasks above are completed and checked off.
A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
All nox stages pass.
Coverage >= 97%.

Automated by CleverAgents Bot
Supervisor: Test Infrastructure | Agent: ca-new-issue-creator

## Metadata - **Branch**: `chore/ci-improve-dependency-caching` - **Commit Message**: `chore(ci): include uv.lock in cache key for deterministic dependency caching` - **Milestone**: v3.8.0 - **Parent Epic**: #1678 ## Background and Context The current dependency caching in `ci.yml` uses a cache key based on `pyproject.toml`. While this is a good starting point, it does not guarantee that the exact same resolved dependency set is used on every CI run. The `uv.lock` file is the authoritative record of the fully-resolved, pinned dependency graph. If `uv.lock` changes (e.g., a transitive dependency is updated) without `pyproject.toml` changing, the cache will not be invalidated and stale dependencies may be used. ## Expected Behavior The cache key in `ci.yml` should include a hash of the `uv.lock` file so that any change to the resolved dependency graph — whether direct or transitive — triggers a fresh cache population. ## Acceptance Criteria - The cache key in `.forgejo/workflows/ci.yml` includes a hash of `uv.lock` in addition to (or instead of) `pyproject.toml`. - A change to `uv.lock` alone causes the cache to be invalidated on the next CI run. - The CI pipeline continues to pass with the updated cache key. ## Subtasks - [ ] Update the cache key in `.forgejo/workflows/ci.yml` to include `hashFiles('uv.lock')` (alongside or replacing the existing `pyproject.toml` hash) - [ ] Verify the updated cache key is syntactically valid in the Forgejo/GitHub Actions workflow format - [ ] Update `features/ci_workflow_validation.feature` to assert the cache key includes `uv.lock` - [ ] Run `nox` (all default sessions) and fix any errors - [ ] Verify coverage >= 97% via `nox -s coverage_report` ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - All nox stages pass. - Coverage >= 97%. --- **Automated by CleverAgents Bot** Supervisor: Test Infrastructure | Agent: ca-new-issue-creator

freemo added this to the v3.8.0 milestone

2026-04-02 23:52:14 +00:00

freemo added a new dependency

2026-04-02 23:56:01 +00:00

#1678 Epic: CI Execution Time Optimization — Timeouts, Concurrency, and Coverage Artifact Sharing

freemo commented

2026-04-03 00:27:16 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
MoSCoW: MoSCoW/Could Have — CI/test infrastructure improvement.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified - **MoSCoW**: MoSCoW/Could Have — CI/test infrastructure improvement. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo added the

MoSCoW

Could have

label

2026-04-03 00:27:17 +00:00