Skip to content

fix(ci): refresh uv.lock before prek to fix stacked PR breakage#302

Merged
ichoosetoaccept merged 1 commit intomainfrom
fix/ci-refresh-lockfile-before-prek
Apr 12, 2026
Merged

fix(ci): refresh uv.lock before prek to fix stacked PR breakage#302
ichoosetoaccept merged 1 commit intomainfrom
fix/ci-refresh-lockfile-before-prek

Conversation

@ichoosetoaccept
Copy link
Copy Markdown
Member

After semantic-release bumps the version on main, remaining stacked
branches have a stale uv.lock. Add a uv lock step before prek in CI
and skip the redundant uv-lock hook to prevent false failures.

Resolves DOT-474

Closes #

After semantic-release bumps the version on main, remaining stacked
branches have a stale uv.lock. Add a uv lock step before prek in CI
and skip the redundant uv-lock hook to prevent false failures.

Resolves DOT-474
@ichoosetoaccept
Copy link
Copy Markdown
Member Author

This change is part of the following stack:

Change managed by git-spice.

@linear
Copy link
Copy Markdown

linear bot commented Apr 12, 2026

@greptile-apps
Copy link
Copy Markdown

greptile-apps bot commented Apr 12, 2026

Greptile Summary

This PR fixes stacked-PR breakage by running uv lock before the prek job in CI (both the template repo's own workflow and the generated project template), then skipping the uv-lock prek hook to avoid a redundant double-run. The approach is straightforward and correctly addresses the root cause — a stale uv.lock after semantic-release bumps the version on main.

Confidence Score: 5/5

Safe to merge — change is narrowly scoped to CI steps with no runtime or template logic impact.

All findings are P2 (a missing companion test). The core logic — run uv lock before prek, skip the uv-lock hook — is correct and consistent across both the template repo's own CI and the generated project template. No P0/P1 issues found.

tests/test_template.py — lacks a test asserting the new uv lock step is present in generated CI workflows.

Important Files Changed

Filename Overview
.github/workflows/ci.yml Adds uv lock step before prek and appends uv-lock to SKIP to prevent redundant hook execution on the template repo's own CI.
project/.github/workflows/ci.yml.jinja Mirrors the same uv lock + SKIP change in the Jinja template so generated projects also get the stale-lockfile fix.
tests/test_template.py Updates SKIP-list assertion to include uv-lock, but no test was added to verify the new uv lock step itself is present in generated CI.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant UV as uv lock
    participant PREK as prek-action

    GH->>GH: checkout branch (stale uv.lock)
    GH->>UV: run uv lock
    UV-->>GH: uv.lock refreshed (version bump applied)
    GH->>PREK: run prek --all-files
    Note over PREK: SKIP includes uv-lock<br/>(already refreshed above)
    PREK-->>GH: hooks pass
Loading

Comments Outside Diff (1)

  1. tests/test_template.py, line 287-293 (link)

    P2 Missing test for the new uv lock step

    The PR updates test_ci_prek_skips_redundant_hooks to cover the SKIP-list change, but there is no assertion that the "Refresh lockfile" step (uv lock) is actually present in the generated CI workflow. If the template step is ever removed or renamed, this gap means the fix would silently regress with no test failure.

    Consider adding a companion test:

    def test_ci_prek_refreshes_lockfile(self, copier_defaults: dict, project_factory) -> None:
        """CI prek job should refresh the lockfile before running hooks."""
        answers = {**copier_defaults, "use_ci": True}
        project = project_factory(answers)
    
        content = (project / ".github" / "workflows" / "ci.yml").read_text()
        assert "uv lock" in content
    Prompt To Fix With AI
    This is a comment left during a code review.
    Path: tests/test_template.py
    Line: 287-293
    
    Comment:
    **Missing test for the new `uv lock` step**
    
    The PR updates `test_ci_prek_skips_redundant_hooks` to cover the SKIP-list change, but there is no assertion that the "Refresh lockfile" step (`uv lock`) is actually present in the generated CI workflow. If the template step is ever removed or renamed, this gap means the fix would silently regress with no test failure.
    
    Consider adding a companion test:
    
    ```python
    def test_ci_prek_refreshes_lockfile(self, copier_defaults: dict, project_factory) -> None:
        """CI prek job should refresh the lockfile before running hooks."""
        answers = {**copier_defaults, "use_ci": True}
        project = project_factory(answers)
    
        content = (project / ".github" / "workflows" / "ci.yml").read_text()
        assert "uv lock" in content
    ```
    
    How can I resolve this? If you propose a fix, please make it concise.

    Fix in Claude Code

Fix All in Claude Code

Prompt To Fix All With AI
This is a comment left during a code review.
Path: tests/test_template.py
Line: 287-293

Comment:
**Missing test for the new `uv lock` step**

The PR updates `test_ci_prek_skips_redundant_hooks` to cover the SKIP-list change, but there is no assertion that the "Refresh lockfile" step (`uv lock`) is actually present in the generated CI workflow. If the template step is ever removed or renamed, this gap means the fix would silently regress with no test failure.

Consider adding a companion test:

```python
def test_ci_prek_refreshes_lockfile(self, copier_defaults: dict, project_factory) -> None:
    """CI prek job should refresh the lockfile before running hooks."""
    answers = {**copier_defaults, "use_ci": True}
    project = project_factory(answers)

    content = (project / ".github" / "workflows" / "ci.yml").read_text()
    assert "uv lock" in content
```

How can I resolve this? If you propose a fix, please make it concise.

Reviews (1): Last reviewed commit: "fix(ci): refresh uv.lock before prek to ..." | Re-trigger Greptile

@ichoosetoaccept ichoosetoaccept merged commit 79e0f81 into main Apr 12, 2026
6 checks passed
@ichoosetoaccept ichoosetoaccept deleted the fix/ci-refresh-lockfile-before-prek branch April 12, 2026 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant