Add pyproject.toml, add Python 3.14 support#577
Conversation
📝 WalkthroughWalkthroughMigrates from setuptools to Poetry-based dependency management in ChangesPoetry Migration and Infrastructure Update
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
20-20:⚠️ Potential issue | 🟠 Major | ⚡ Quick winCI matrix includes unsupported Python 3.11
.github/workflows/ci.ymlstill testspython-version: ["3.11", "3.12", "3.13"]for bothflake8(line 20) andtest(line 44), butpyproject.tomlsetsrequires-python = ">=3.12", sopip install ".[dev]"/pip install ".[test]"will be rejected on 3.11.Suggested change
- python-version: ["3.11", "3.12", "3.13"] + python-version: ["3.12", "3.13"]🤖 Prompt for 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. In @.github/workflows/ci.yml at line 20, CI is testing Python 3.11 even though pyproject.toml requires ">=3.12"; update .github/workflows/ci.yml to remove 3.11 from the python-version matrix for the flake8 and test jobs by changing the python-version entries (the "python-version" array) to only include ["3.12", "3.13"] so the CI matrix matches requires-python and pip install ".[dev]" / ".[test]" won't be rejected.
🤖 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 `@Dockerfile`:
- Line 51: Replace the hardcoded path in the RUN step that cats
/venv/lib/python3.12/site-packages/asab/__version__.py with a dynamic
Python-based lookup: run a small python snippet that imports the asab package,
resolves its installation path (e.g., via asab.__file__ or sysconfig/site APIs)
and prints the contents of the corresponding __version__.py; update the RUN
command that currently contains "cat
/venv/lib/python3.12/site-packages/asab/__version__.py" to use that dynamic
approach so the Docker build won’t break on Python minor version bumps.
In `@pyproject.toml`:
- Line 68: The git VCS dependency string "asab[encryption] @
git+https://github.com/TeskaLabs/asab.git" is unpinned and can change between
installs; update both occurrences of that dependency to reference an immutable
ref by appending either a tag or commit hash (for example: "asab[encryption] @
git+https://github.com/TeskaLabs/asab.git@vX.Y.Z" or "...@<commit-sha>") so
installs are reproducible, and ensure both lines (the two occurrences) are
updated consistently.
---
Outside diff comments:
In @.github/workflows/ci.yml:
- Line 20: CI is testing Python 3.11 even though pyproject.toml requires
">=3.12"; update .github/workflows/ci.yml to remove 3.11 from the python-version
matrix for the flake8 and test jobs by changing the python-version entries (the
"python-version" array) to only include ["3.12", "3.13"] so the CI matrix
matches requires-python and pip install ".[dev]" / ".[test]" won't be rejected.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: d1c6a43a-c1e8-488c-a78f-51de59527d73
📒 Files selected for processing (5)
.dockerignore.github/workflows/ci.yml.gitignoreDockerfilepyproject.toml
|
Actionable comments posted: 0 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/ci.yml:
- Line 57: The pip install command on line 57 of the CI workflow duplicates test
dependencies already declared in the test extra in pyproject.toml and keeps the
asab[encryption] Git dependency unpinned, reducing reproducibility. Replace the
entire hardcoded pip install line with a single command that installs the test
extra from the current project using pip install ".[test]", and then update the
asab[encryption] dependency in pyproject.toml (around lines 81-87 in the test
extra definition) to pin the Git URL to a specific commit hash or tag by
appending @<commit-hash> or @<tag> to the end of the Git URL.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 92c85697-038e-4ad5-a64f-280eca56e027
📒 Files selected for processing (3)
.github/workflows/ci.ymlDockerfilepyproject.toml
🚧 Files skipped from review as they are similar to previous changes (2)
- Dockerfile
- pyproject.toml
byewokko
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
1-15:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd explicit GitHub Actions token permissions.
Line 1 currently relies on default token permissions; that is broader than necessary. Define least-privilege
permissionsat workflow (or per-job) scope.Suggested change
name: CI +permissions: + contents: read🤖 Prompt for 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. In @.github/workflows/ci.yml around lines 1 - 15, The CI workflow is currently relying on default GitHub Actions token permissions which are broader than necessary and violate the principle of least privilege. Add an explicit `permissions` block in the workflow file after the `on:` trigger section and before the `jobs:` section to define only the minimum permissions required for the workflow tasks. Specify permissions such as contents (for repo access), pull-requests (if needed for PR operations), and any other specific permissions the workflow actually uses, while omitting unnecessary default permissions.Source: Linters/SAST tools
🧹 Nitpick comments (1)
Dockerfile (1)
2-2: ⚡ Quick winPin Alpine base images by digest.
Lines 2 and 61 use mutable tags (
alpine:3.24). Pinning to image digests improves reproducibility and reduces supply-chain drift.Suggested change
-FROM alpine:3.24 AS builder +FROM alpine:3.24@sha256:<builder-digest> AS builder ... -FROM alpine:3.24 +FROM alpine:3.24@sha256:<runtime-digest>Also applies to: 61-61
🤖 Prompt for 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. In `@Dockerfile` at line 2, The Dockerfile is using mutable Alpine tags (alpine:3.24) in the FROM statements at line 2 for the builder stage and at line 61. Replace these mutable tags with their specific image digests (in the format alpine@sha256:...) to ensure reproducibility and reduce supply-chain drift. Pin both occurrences of the Alpine base image to their corresponding digest hashes rather than relying on the mutable tag.
🤖 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/ci.yml:
- Around line 30-33: The Poetry installation commands lack version pinning,
which can cause workflow failures when new versions introduce breaking changes.
In the "Install Poetry" step and any other Poetry installation commands in the
workflow, replace the generic pip install poetry command with pip install
poetry==<specific-version> where you pin to a stable tested version (for
example, a recent stable release). Apply this fix to both occurrences mentioned
in the comment to ensure reproducible builds across all CI jobs.
- Around line 89-93: The docker/login-action is currently pinned to the mutable
tag `@v3`, which poses a security risk. Replace `@v3` with a pinned full commit SHA
(for example, `@abc123def456`...). Additionally, add the version tag as a comment
on the same line (e.g., # v3) to enable automated dependency tools like
Dependabot to track and update the SHA when new versions are released. This
follows industry-standard security practices for GitHub Actions workflows.
---
Outside diff comments:
In @.github/workflows/ci.yml:
- Around line 1-15: The CI workflow is currently relying on default GitHub
Actions token permissions which are broader than necessary and violate the
principle of least privilege. Add an explicit `permissions` block in the
workflow file after the `on:` trigger section and before the `jobs:` section to
define only the minimum permissions required for the workflow tasks. Specify
permissions such as contents (for repo access), pull-requests (if needed for PR
operations), and any other specific permissions the workflow actually uses,
while omitting unnecessary default permissions.
---
Nitpick comments:
In `@Dockerfile`:
- Line 2: The Dockerfile is using mutable Alpine tags (alpine:3.24) in the FROM
statements at line 2 for the builder stage and at line 61. Replace these mutable
tags with their specific image digests (in the format alpine@sha256:...) to
ensure reproducibility and reduce supply-chain drift. Pin both occurrences of
the Alpine base image to their corresponding digest hashes rather than relying
on 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: ed07dbcb-dbd8-4470-b7b7-972dfbaffca3
📒 Files selected for processing (6)
.dockerignore.github/workflows/ci.yml.gitignoreCHANGELOG.mdDockerfilepyproject.toml
✅ Files skipped from review due to trivial changes (2)
- CHANGELOG.md
- pyproject.toml
🚧 Files skipped from review as they are similar to previous changes (2)
- .gitignore
- .dockerignore
| - name: Install Poetry | ||
| run: | | ||
| python -m pip install --upgrade pip | ||
| pip install flake8 | ||
| pip install git+https://github.com/TeskaLabs/asab.git | ||
|
|
||
| pip install poetry |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/ci.yml | head -100Repository: TeskaLabs/seacat-auth
Length of output: 2935
Pin Poetry to a fixed version in both CI jobs for reproducible builds.
Poetry is installed without version pinning at lines 33 and 61, which can cause workflows to break when new Poetry versions introduce breaking changes. Pin to a specific tested version.
Suggested change
- pip install poetry
+ pip install "poetry==<approved-version>"🤖 Prompt for 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.
In @.github/workflows/ci.yml around lines 30 - 33, The Poetry installation
commands lack version pinning, which can cause workflow failures when new
versions introduce breaking changes. In the "Install Poetry" step and any other
Poetry installation commands in the workflow, replace the generic pip install
poetry command with pip install poetry==<specific-version> where you pin to a
stable tested version (for example, a recent stable release). Apply this fix to
both occurrences mentioned in the comment to ensure reproducible builds across
all CI jobs.
| - name: Login to DockerHub | ||
| uses: docker/login-action@v3 | ||
| with: | ||
| username: ${{ secrets.DOCKER_USER }} | ||
| password: ${{ secrets.DOCKER_PASSWORD }} | ||
| username: ${{ secrets.DOCKER_USER }} | ||
| password: ${{ secrets.DOCKER_PASSWORD }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions best practices pinning commit SHA vs tag 2024 2025
💡 Result:
The industry-standard best practice for GitHub Actions is to pin references to a full-length commit SHA rather than a version tag or branch name [1][2][3]. This approach provides security through immutability, ensuring that your workflow consistently runs the exact same code you have reviewed, regardless of changes made to the upstream repository [1][4][5]. Why Pin to a Commit SHA GitHub tags (e.g., @v4) are mutable references that can be moved, deleted, or recreated by an action's maintainer [4][5][6]. A compromised maintainer account or a malicious actor can retarget these tags to point at compromised code, causing your CI/CD pipelines to execute unauthorized actions and potentially expose sensitive secrets [2][7][6]. Pinning to an immutable full-length commit SHA eliminates this supply chain risk, as an attacker cannot change the content of a Git commit without generating a collision [1][8][3]. Implementation Strategy To maintain the readability and updateability of your workflows, use the following pattern: - Pin to the full 40-character commit SHA [1][6]. - Include the version tag as a comment on the same line to keep the reference human-readable and compatible with automated dependency tools [8][2][5]. Example: - uses: actions/checkout@3df4ab1 # v4.0.0 Managing Updates Manually updating SHAs is inefficient. Instead, automate the process using dependency management tools like Dependabot or Renovate [8][2][7]. Both tools support the "SHA-pin with tag comment" convention; they parse the comment to identify the latest version and open pull requests to bump the SHA and update the comment simultaneously [8][5]. Enforcement - Organizational Policy: GitHub allows administrators to enforce full commit SHA pinning at the repository or organization level [1][4][2]. When enabled, any workflow referencing an action by a mutable tag or branch will fail, blocking unpinned dependencies [4][2]. - Automated Checks: For environments where a policy isn't enforced, you can integrate tools like zizmor or custom scripts into your CI pipeline to scan and reject workflows that use mutable references [2][6]. Exceptions While pinning to a SHA is the recommended standard for all third-party actions, some organizations allow tag-based references for internal, first-party actions over which they maintain full, direct control [6]. However, for all external dependencies, SHA pinning is widely considered a required security practice [2][3][6].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 3: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash/
- 6: https://safeguard.sh/resources/blog/how-to-pin-github-actions-to-shas-correctly
- 7: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 8: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
🌐 Web query:
docker/login-action versioning recommendations security
💡 Result:
For the docker/login-action GitHub Action, security best practices focus on minimizing supply chain risk through strict versioning and adhering to secure credential management. Versioning Recommendations To protect against supply chain compromises where malicious code could be injected into action updates, it is highly recommended to pin the action to a specific immutable commit SHA rather than a semantic version tag [1]. While semantic version tags (e.g., v4) are convenient, they are mutable and can be updated by maintainers; pinning to a full-length commit hash ensures that the exact code you have reviewed and tested is always executed [1]. Credential Security Best Practices 1. Use Scoped Credentials: When possible, use the scope input to limit registry credentials to a specific repository or namespace [2][3]. This prevents the action from overriding global Docker credentials, which is particularly useful for maintaining unauthenticated pull capabilities for base images while authenticating only for necessary push operations [2][3]. 2. Prefer Repository Variables for Usernames: Use GitHub Actions variables (vars) for usernames instead of secrets [4]. Secrets are automatically redacted from logs, but using them for non-sensitive data can sometimes lead to excessive masking that obscures useful debugging information; variables provide a clearer, more appropriate storage mechanism for non-sensitive identity information [5][4]. 3. Use Personal Access Tokens (PATs) or GITHUB_TOKEN: - For Docker Hub: Never use your main account password. Always use a dedicated Personal Access Token (PAT) with appropriate, limited scopes [2][6]. - For GitHub Container Registry (ghcr.io): Use the built-in GITHUB_TOKEN, which provides the most secure and streamlined authentication experience for actions within a repository [6][7][8]. 4. Automatic Logout: The action defaults to logout: true, which is a security best practice that ensures credentials are not left in the runner's environment after the job completes [2][3]. Maintain this default setting unless there is a specific, well-justified reason to change it. 5. Consider Third-Party Alternatives: If highly specialized security environments are required, community-maintained drop-in replacements that emphasize enhanced security posture (such as those provided by organizations specializing in CI/CD security) may be evaluated [9]. Always monitor the official repository releases and changelogs to stay informed about dependency updates and security patches [10][11].
Citations:
- 1: https://blog.gitguardian.com/github-actions-security-cheat-sheet/
- 2: https://github.com/docker/login-action
- 3: https://github.com/docker/login-action?tab=readme-ov-file
- 4: docker/login-action@2b0e0e0
- 5: ensure passwords are redacted with registry-auth docker/login-action#911
- 6: https://github.com/docker/login-action/blob/02c9ff3be2fc1b56f9ab4494083e97e918fa8089/README.md
- 7: https://github.com/marketplace/actions/docker-login?version=v2.2.0
- 8: https://github.com/marketplace/actions/docker-login?version=v3.1.0
- 9: https://github.com/step-security/docker-login-action
- 10: https://github.com/docker/login-action/releases
- 11: https://github.com/docker/login-action/releases/tag/v4.0.0
🌐 Web query:
GitHub Actions security supply chain integrity pinning versions
💡 Result:
To ensure supply chain integrity in GitHub Actions, the most critical security practice is to pin all third-party actions to their full-length commit SHA [1][2][3]. Why Pinning to SHA is Required Standard Git tags (e.g., @v1, @v2) are mutable, meaning an attacker or a compromised maintainer account can move a tag to point to a different, malicious commit [4][5][6]. Pinning to a full-length commit SHA ensures that the action remains immutable, as the SHA uniquely identifies the exact state of the code [1][4][6]. This protects workflows against "tag retargeting" attacks [5]. Policy Enforcement GitHub provides features to enforce this security posture at scale [4]. Organization and repository administrators can configure "Allowed Actions" policies to require that all actions be pinned to a full-length commit SHA [4][3]. When enabled, any workflow attempting to use an action not pinned to a SHA will fail, preventing the accidental use of unverified or mutable versions [4]. Best Practices for Implementation - Automated Maintenance: While SHA pinning increases security, it creates a manual maintenance burden for updates [7]. Use automated dependency management tools like Dependabot or Renovate to keep these SHAs updated [2][5][6]. These tools can propose pull requests that update the commit SHA while often maintaining a human-readable tag in a comment for context [5][6]. - Trust and Verification: Even when pinned, you should only use actions from reputable creators [1][3]. For actions from less-trusted sources, consider vetting the code or forking it into your own organization for controlled use [7]. - Holistic Security: Pinning is one layer of a secure supply chain. Complement this with other strategies: - Enable CodeQL to scan workflows for security best practices [2]. - Utilize OpenID Connect (OIDC) to eliminate the need for long-lived secrets in workflows [2]. - Use security tools like Scorecards, zizmor, or StepSecurity's Harden-Runner to detect risky practices and monitor runtime behavior [1][7][6]. For developers looking to automate the transition to SHA pinning, community tools such as pinact, frizbee, or ratchet can help identify and replace existing tag references with immutable digests [8][6].
Citations:
- 1: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 2: https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-across-github/
- 3: https://docs.github.com/en/actions/reference/security/secure-use
- 4: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://www.cncf.io/blog/2026/05/04/securing-github-actions-ci-dependencies-recipe-card/
- 7: https://www.stepsecurity.io/blog/github-actions-security-best-practices
- 8: https://github.com/suzuki-shunsuke/pinact
Pin docker/login-action to a full commit SHA.
Line 90 uses a mutable tag (@v3). Pinning to a full commit SHA is the industry-standard security practice and improves supply-chain integrity by preventing tag-retargeting attacks where a compromised maintainer account or malicious actor could redirect the tag to malicious code.
For maintainability, include the version tag as a comment on the same line so automated dependency tools like Dependabot can keep the SHA updated:
Suggested change
- uses: docker/login-action@v3
+ uses: docker/login-action@<full-commit-sha> # v3🧰 Tools
🪛 zizmor (1.25.2)
[error] 90-90: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for 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.
In @.github/workflows/ci.yml around lines 89 - 93, The docker/login-action is
currently pinned to the mutable tag `@v3`, which poses a security risk. Replace
`@v3` with a pinned full commit SHA (for example, `@abc123def456`...). Additionally,
add the version tag as a comment on the same line (e.g., # v3) to enable
automated dependency tools like Dependabot to track and update the SHA when new
versions are released. This follows industry-standard security practices for
GitHub Actions workflows.
Source: Linters/SAST tools
1 participant
Summary
Summary by CodeRabbit
Release Notes
New Features
Chores