Skip to content

update flake and workflows nix setup#449

Merged
rouzwelt merged 3 commits into
masterfrom
2026-06-16-update-flake-and-workflows
Jun 17, 2026
Merged

update flake and workflows nix setup#449
rouzwelt merged 3 commits into
masterfrom
2026-06-16-update-flake-and-workflows

Conversation

@rouzwelt

@rouzwelt rouzwelt commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Motivation

This PR updates flake to latest and updates workflow nix setup to unified raining repo setting

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

  • made this PR as small as possible
  • unit-tested any new functionality
  • linked any relevant issues or PRs
  • included screenshots (if this involves a front-end change)

Summary by CodeRabbit

  • Chores
    • Updated CI/CD pipeline infrastructure to enhance build performance and reliability. Optimized Nix environment configuration and caching mechanisms across multiple automated workflows.

@rouzwelt rouzwelt self-assigned this Jun 16, 2026
@rouzwelt rouzwelt added the general update A general update to the repo label Jun 16, 2026
@coderabbitai

coderabbitai Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@rouzwelt, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 42 minutes and 56 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: bb687282-0b4b-4ffd-87b3-5457f39d99e3

📥 Commits

Reviewing files that changed from the base of the PR and between 71d6deb and 12c8b5e.

📒 Files selected for processing (1)
  • .github/workflows/standard-test.yaml

Walkthrough

All five CI workflow files replace the DeterminateSystems Nix installer and flakehub cache steps with three new actions: nixbuild/nix-quick-install-action@v30, cachix/cachix-action@v15 (authenticated via CACHIX_AUTH_TOKEN, continue-on-error: true), and nix-community/cache-nix-action@v6 keyed by runner OS plus hashes of **/*.nix and flake.lock, with a 10G Linux GC store size cap.

Changes

Nix Caching Stack Migration

Layer / File(s) Summary
Nix setup replacement in all workflows
.github/workflows/build-docker.yaml, .github/workflows/deploy-preview.yml, .github/workflows/git-clean.yaml, .github/workflows/standard-publish.yaml, .github/workflows/standard-test.yaml
Removes DeterminateSystems Nix installer and flakehub cache steps from all workflows. Adds nixbuild/nix-quick-install-action@v30, cachix/cachix-action@v15 (with CACHIX_AUTH_TOKEN and continue-on-error: true), and nix-community/cache-nix-action@v6 (OS+hash primary key, gc-max-store-size-linux: 10G). standard-test.yaml applies the replacement to both unit-test and e2e-test jobs and additionally enables keep-env-derivations and keep-outputs in the Nix config. git-clean.yaml also sets useDaemon: false on the Cachix step.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main changes across multiple workflow files, which involve updating Nix setup in GitHub Actions workflows and updating the flake configuration.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 2026-06-16-update-flake-and-workflows

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build-docker.yaml:
- Around line 29-42: The three GitHub Actions in the build-docker.yaml workflow
are pinned to mutable version tags which pose a supply chain security risk.
Replace the mutable tag references for `nixbuild/nix-quick-install-action@v30`,
`cachix/cachix-action@v15`, and `nix-community/cache-nix-action@v6` with their
full immutable commit SHAs. You can find the correct commit SHA for each action
by checking the release or commit history on GitHub, then update each uses
statement to reference the full SHA instead of the version tag. Optionally, add
a comment next to each pinned SHA documenting which release version it
corresponds to for maintainability.

In @.github/workflows/deploy-preview.yml:
- Around line 25-38: Replace the mutable version tags used in the GitHub Actions
with immutable full commit SHAs to eliminate supply chain risks. For each action
reference (nixbuild/nix-quick-install-action, cachix/cachix-action, and
nix-community/cache-nix-action), change the format from `@vXX` to
@<full-commit-sha> and add the version tag as an inline comment for readability
(e.g., # vXX). This prevents version tags from being retargeted by attackers and
ensures only the exact intended code is executed.

In @.github/workflows/git-clean.yaml:
- Around line 16-29: The three GitHub Actions in the workflow file use mutable
version tags that pose supply-chain security risks. Replace the mutable tags in
nixbuild/nix-quick-install-action (`@v30`), cachix/cachix-action (`@v15`), and
nix-community/cache-nix-action (`@v6`) with their full 40-character commit SHAs.
For each action, use the format owner/action@<40-char-sha> # v<version> to
maintain clarity about which version the SHA corresponds to. This pins the
actions to immutable commits, preventing any unintended upstream modifications
from affecting your workflows.

In @.github/workflows/standard-publish.yaml:
- Around line 33-46: The standard-publish.yaml workflow uses mutable version
tags for third-party actions instead of immutable commit SHAs, which poses a
security risk. Replace the version tags with full commit SHAs for the following
actions: nixbuild/nix-quick-install-action, cachix/cachix-action,
nix-community/cache-nix-action, and actions/checkout. For each action, look up
the specific commit SHA for the desired version and update the uses field to
reference that SHA instead of the version tag (e.g., change `@v30` to
@<full-commit-sha>).
- Around line 48-50: The cache restore strategy in the publish job is vulnerable
to cache poisoning because the broad restore-prefixes-first-match pattern allows
fallback to cache entries from any earlier run on the same branch. To fix this,
modify the primary-key to include the GitHub ref name (add ${{ github.ref }} to
the key) and remove or make the restore-prefixes-first-match more restrictive so
that only exact or very specific cache matches are used during release builds,
eliminating the fallback to potentially poisoned cache entries from other
workflow runs.

In @.github/workflows/standard-test.yaml:
- Around line 22-35: Replace all mutable version tag references with immutable
40-character commit SHAs for external GitHub Actions to mitigate supply-chain
risks. In both the unit-test and e2e-test jobs, update the `uses:` statements
for nixbuild/nix-quick-install-action, cachix/cachix-action, and
nix-community/cache-nix-action from their current version tags (v30, v15, and v6
respectively) to their full commit SHA hashes. For each action, look up the
specific commit SHA that corresponds to the version tag you're replacing and
update the reference to use the format owner/repo@{full-40-character-SHA}
instead of the mutable tag.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 82f11bd6-bd66-46cc-af73-c3ea32d212ed

📥 Commits

Reviewing files that changed from the base of the PR and between 1bf23b1 and 71d6deb.

⛔ Files ignored due to path filters (1)
  • flake.lock is excluded by !**/*.lock
📒 Files selected for processing (5)
  • .github/workflows/build-docker.yaml
  • .github/workflows/deploy-preview.yml
  • .github/workflows/git-clean.yaml
  • .github/workflows/standard-publish.yaml
  • .github/workflows/standard-test.yaml

Comment thread .github/workflows/build-docker.yaml
Comment thread .github/workflows/deploy-preview.yml
Comment thread .github/workflows/git-clean.yaml
Comment thread .github/workflows/standard-publish.yaml
Comment thread .github/workflows/standard-publish.yaml
Comment thread .github/workflows/standard-test.yaml
@rouzwelt rouzwelt merged commit 3da315d into master Jun 17, 2026
12 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

coderabbitai Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

SIZE=M

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

general update A general update to the repo

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant