fix Ci

[asuiu]

Title

<type>: <short summary>

Ticket / Task

• [Trello|Jira] link: <URL>

What & Why

"Builds X so that Y can Z" – two sentences max.

Scope

• New feature
• Bug fix
• Refactor / tech-debt
• Test / tooling only

Checklist (self-review)

See Section 5.

Risk / Impact

• Latency critical path? ☐ Yes ☐ No
• External API contract change? ☐ Yes ☐ No
• Migration steps required? ☐ Yes ☐ No

Screenshots / Logs / Benchmarks

(only if relevant)

Author Self-Review Checklist

• Single Ticket — PR addresses only one business requirement / Trello card.
• Minimal Diff — no unrelated refactors, commented-out code, or debug prints.
• Compiles & Tests Pass — pytest -q / mvn test clean locally.
• No Dead Code — every new unit is called or covered by tests.
• Naming & Clarity — identifiers are self-explanatory; no overloaded meanings.
• Docs Updated — README, wiki, or docstrings updated where behaviour changed.
• Performance Tagged — if touching hot path, attach micro-benchmarks or profiler diff.
• Config & Secrets — no plaintext credentials; configs externalised.
• Rollback Ready — change can be reverted with git revert without dependency hell.
• Checklist Acknowledged — I would merge this myself if I were the reviewer.
• LLM Review — PR has been reviewed by the approved LLM tool and suggestions addressed.
  • IDE Type Checker — PyCharm/Pylance recommendations were addressed where applicable.
  • Optional mypy — (Recommended) Ran python/scripts/run_mypy.bat locally with no critical errors

Resources:

• PR guidelines

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Bumped package version to 1.5.1.
  • Updated dependency constraints and added development dependencies to improve stability and build reliability.

Walkthrough

The pull request updates the CI/CD workflow to explicitly lock Poetry dependencies before installation via two new poetry lock steps in the python directory, and bumps the package version from 1.5.0 to 1.5.1 while standardizing the filelock dependency constraint and adding psutil as a development dependency.

Changes

Cohort / File(s)	Summary
CI Workflow Updates .github/workflows/python-package.yml	Adds cd python && poetry lock commands before the main Python install step and before the container install step to lock dependencies prior to installation
Package Manifest python/pyproject.toml	Bumps version from 1.5.0 to 1.5.1; standardizes filelock constraint from >3.20.0 to >=3.20.0; adds psutil ^7.1.3 as a development dependency

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

• Workflow changes are repetitive and straightforward
• Dependency and version updates are declarative with no logic implications

Poem

🔒 Lock the graph before the install,
Bump to 1.5.1—reliability won't stall,
Psutil for dev, filelock constrained tight,
Dependencies predictable, systems in flight ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	PR description is entirely unmodified boilerplate template with no actual content filled in; all sections are empty placeholders.	Complete the PR description by filling in actual content: provide a type and summary in Title, add ticket link, explain what changes are being made and why, select appropriate Scope, and acknowledge self-review checklist items.
Title check	❓ Inconclusive	Title is vague and doesn't meaningfully convey what was changed; 'fix Ci' lacks specificity about CI fixes and doesn't reflect the actual changes (Poetry lock additions and dependency updates).	Use a more specific title like 'Add Poetry dependency locking to CI workflows and bump version' that clearly describes the actual changes being made.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch test-ci

---

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

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e9e8147 and 9da51ef.

⛔ Files ignored due to path filters (1)

• python/poetry.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• .github/workflows/python-package.yml (2 hunks)
• python/pyproject.toml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: build (macos-latest, 3.11)
• GitHub Check: build (macos-latest, 3.10)
• GitHub Check: build (windows-latest, 3.14)

🔇 Additional comments (2)

python/pyproject.toml (2)

32-32: psutil is actually being used—the review comment is unfounded.

The dependency isn't mysterious or dead code. It's explicitly imported and used in python/tests/test_backup_multi_bucket.py to get process information. It's also pulled in as a transitive dependency by several packages (dmypy, optional extras for other dependencies). No action needed—this is solid engineering.

Likely an incorrect or invalid review comment.

---

16-16: Let me dig deeper into the repository context to understand if this constraint change was intentional.

Now let me check the repository context to understand whether this change was intentional.

Based on my verification, let me generate the final response:

---

The constraint relaxation is accurate, but the terminology is misleading.

Changed from > 3.20.0 to >=3.20.0—this allows filelock 3.20.0, which was previously excluded. This is a constraint relaxation, not "standardizing" as the AI summary claims.

The good news: filelock 3.20.0 is actively packaged and available across distributions (Arch Linux, Debian, MSYS2), and there are no known issues with that version. Allowing it expands compatibility without risk.

The open question: Was this change intentional, or did someone flip the operator without thinking? Without commit context, it's hard to say. If you're relaxing constraints deliberately for better dependency compatibility, this is fine. If it was accidental, you should clarify the constraint logic.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Lock generation on every build is sound, but verify it aligns with your lock file strategy.

You're running poetry lock before install to update the lock file to match pyproject.toml without installing dependencies. This is legitimate practice for catching broken dependencies early. However, the pattern regenerates locks on every CI run across multiple Python/OS combinations, which could lead to:

• Lock file diffs appearing in CI artifacts if not committed properly
• Platform-specific lock differences if lock file isn't standardized

Suggestion: Commit the poetry.lock file to your version control system to ensure all developers and CI environments use identical dependency versions. If already doing that, consider whether you need poetry lock each run or only when dependencies change.

Also applies to: 58-59

🤖 Prompt for AI Agents

.github/workflows/python-package.yml lines 35-36 (and similarly 58-59): CI runs
`poetry lock` on every build which can cause uncommitted lock diffs and
platform-specific lock divergence; ensure you commit poetry.lock to the repo and
remove the unconditional `poetry lock` step from CI (or make it conditional/run
only when pyproject.toml changes) so CI uses the committed lockfile consistently
across platforms.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Version sync is broken — tool.poetry and tool.commitizen are out of sync.

Line 3 says the version is kept in sync with tool.commitizen via automation, but you've bumped poetry to 1.5.1 while commitizen is still 1.2.3. If the sync is real, either the automation failed or wasn't run. If it's aspirational, that comment is misleading.

Either:

1. Update commitizen to 1.5.1 to actually keep them in sync, or
2. Remove the sync comment if automation isn't real.

-version = "1.2.3"  # do not edit manually. kept in sync with `tool.poetry` config via automation
+version = "1.5.1"  # do not edit manually. kept in sync with `tool.poetry` config via automation

Also applies to: 80-80

🤖 Prompt for AI Agents

In python/pyproject.toml around lines 3 and 80, the file claims the version is
"kept in sync with `tool.commitizen` via automation" but the versions differ
(poetry bumped to 1.5.1 while commitizen remains 1.2.3); either update the
commitizen version to match 1.5.1 (and run the automation if required) or
remove/adjust the misleading sync comment so it accurately reflects reality;
make the change consistently in both occurrences (line 3 and line 80).