Add GitHub Actions workflow for Python package

[eshirvana]

This workflow installs Python dependencies, runs linting with flake8, and executes tests with pytest across multiple Python versions.

Greptile Summary

The workflow now runs dependency installation, linting, and tests on the project’s supported Python 3.10 and 3.11 versions.

• Runs on pushes and pull requests targeting main.
• Installs runtime and test dependencies before executing flake8 and pytest.
• Removes the unsupported Python 3.9 matrix entry.

Confidence Score: 3/5

The PR should not merge until the still-mutable third-party action references are pinned to immutable commit SHAs.

The unsupported Python 3.9 entry has been removed, but both third-party actions still resolve through mutable tags, leaving the previously reported CI integrity issue outstanding.

Files Needing Attention: .github/workflows/python-package.yml

Important Files Changed

Filename	Overview
.github/workflows/python-package.yml	Adds the Python CI workflow and now uses a supported interpreter matrix.

_{Reviews (2): Last reviewed commit: "Update .github/workflows/python-package...." | Re-trigger Greptile}

[qodo-code-review]

PR Summary by Qodo

Add GitHub Actions CI to lint and test Python package (3.9–3.11)

⚙️ Configuration changes 🧪 Tests 🕐 10-20 Minutes

AI Description

• Add GitHub Actions workflow triggered on pushes and PRs to main.
• Run flake8 linting and pytest test suite across Python 3.9–3.11.
• Install dependencies via pip, including optional requirements.txt support.

Diagram

graph TD
  GH{{"GitHub Actions"}} --> WF[".github/workflows/python-package.yml"] --> CO["Checkout repo"] --> PY["Setup Python (3.9–3.11)"] --> DEP["Install deps"] --> LINT["flake8 lint"] --> TEST["pytest tests"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use tox/nox as the single CI entrypoint

• ➕ Keeps local and CI environments consistent
• ➕ Centralizes Python matrix and lint/test commands in one tool
• ➖ Introduces an additional tool/config file to maintain
• ➖ May be unnecessary for small projects

2. Add pip caching (actions/cache or setup-python cache: pip)

• ➕ Significantly speeds up repeated CI runs
• ➕ Reduces network flakiness from repeated installs
• ➖ Slightly more workflow complexity
• ➖ Cache invalidation needs care when dependency sources change

3. Pin and modernize action versions (e.g., setup-python@v5)

• ➕ Reduces risk from unexpected action behavior changes
• ➕ Access to newer features and security fixes
• ➖ Requires occasional maintenance to update pins

Recommendation: The current workflow is a solid minimal baseline for CI. Consider adding pip caching and updating/pinning action versions next for faster, more predictable runs; adopt tox/nox only if you want a single shared developer+CI test matrix.

Files changed (1) +40 / -0

Other (1) +40 / -0

python-package.ymlAdd CI workflow for linting and pytest across Python 3.9–3.11 +40/-0

Add CI workflow for linting and pytest across Python 3.9–3.11

• Introduces a GitHub Actions workflow triggered on push and pull_request to main. The job sets up a Python version matrix, installs dependencies (including optional requirements.txt), runs flake8 linting, and executes pytest.

.github/workflows/python-package.yml

[greptile-apps]

Mutable workflow action references

The workflow references actions/checkout@v4 and actions/setup-python@v3 through mutable tags, allowing the executed CI code to change without repository review. Pinning each action to a full commit SHA protects checked-out source and build integrity from a moved or compromised tag.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/python-package.yml
Line: 22-24

Comment:
**Mutable workflow action references**

The workflow references `actions/checkout@v4` and `actions/setup-python@v3` through mutable tags, allowing the executed CI code to change without repository review. Pinning each action to a full commit SHA protects checked-out source and build integrity from a moved or compromised tag.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unpinned/outdated GH actions 🐞 Bug ⛨ Security

Description

The workflow uses mutable tag references for actions (e.g., checkout@v4 and setup-python@v3), which
increases supply-chain risk and reduces build reproducibility. setup-python@v3 is also behind
current major releases, missing fixes and improvements.

Code

.github/workflows/python-package.yml[R22-25]

+    - uses: actions/checkout@v4
+    - name: Set up Python ${{ matrix.python-version }}
+      uses: actions/setup-python@v3
+      with:

Evidence

The workflow uses tag-pinned actions and an older setup-python major version directly in the added
workflow steps.

.github/workflows/python-package.yml[21-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow references GitHub Actions by mutable tags (e.g., `@v4`, `@v3`) rather than immutable commit SHAs, and uses an older major version of `actions/setup-python`.

### Issue Context
Mutable tags can move over time, changing what code executes in CI.

### Fix Focus Areas
- .github/workflows/python-package.yml[22-26]

### Suggested fix
- Upgrade `actions/setup-python` to a current major version.
- Pin third-party actions to commit SHAs (optionally keep the tag in a comment) and use Dependabot to keep pins updated.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Package not installed in CI 🐞 Bug ☼ Reliability

Description

The workflow installs tools and requirements.txt but never installs the project itself, so CI won’t
catch packaging issues (missing files in the wheel/sdist, dependency metadata drift, or the
console-script entry point). This can allow releases that pass tests from a checkout but fail when
installed by users.

Code

.github/workflows/python-package.yml[R28-31]

+      run: |
+        python -m pip install --upgrade pip
+        python -m pip install flake8 pytest
+        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

Evidence

The workflow only installs flake8/pytest and optionally requirements.txt, but does not install the
package; meanwhile pyproject.toml defines a packaged project and a console script entry point that
CI currently doesn’t validate.

.github/workflows/python-package.yml[27-31]
pyproject.toml[5-34]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CI runs pytest from the checked-out source tree without ever installing the project. This skips validation of packaging metadata and entry points.

### Issue Context
The project declares a console script (`fitbit2garmin`) in `pyproject.toml`, which should be validated as part of CI.

### Fix Focus Areas
- .github/workflows/python-package.yml[27-31]
- pyproject.toml[5-34]

### Suggested fix
- After installing dependencies, run one of:
 - `python -m pip install -e .` (editable)
 - or build and install a wheel in a clean env for stronger validation.
- Prefer installing dependencies from the project metadata (e.g., `pip install .`) rather than maintaining a separate requirements.txt as the single source of truth (unless requirements.txt is intentionally the canonical lock/source).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Flake8 not enforced 🐞 Bug ⚙ Maintainability

Description

The second flake8 invocation uses --exit-zero, so most lint violations won’t fail CI and the "Lint"
step won’t enforce style/complexity constraints. Only the first, select-limited flake8 command can
fail the build.

Code

.github/workflows/python-package.yml[R35-37]

+        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
+        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
+        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

Evidence

The workflow explicitly includes --exit-zero in the lint command, which makes flake8 return
success regardless of most findings.

.github/workflows/python-package.yml[32-37]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow’s flake8 step uses `--exit-zero`, which forces success even when lint violations are found.

### Issue Context
The first flake8 command only checks a narrow set of error codes; the second command is where broader lint rules would normally be enforced.

### Fix Focus Areas
- .github/workflows/python-package.yml[32-37]

### Suggested fix
- Remove `--exit-zero` so lint violations fail the job, OR rename/split the step to clearly indicate that the second pass is advisory (e.g., upload as annotations) if non-blocking lint is intended.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View medium (1)

4. Unsupported Python in matrix ✓ Resolved 🐞 Bug ≡ Correctness

Description

The workflow includes Python 3.9 even though the project declares requires-python >=3.10, so CI
results won’t reflect supported runtimes and may miss version-policy regressions. Align the matrix
with the supported versions declared in pyproject.toml.

Code

.github/workflows/python-package.yml[R18-20]

+      matrix:
+        python-version: ["3.9", "3.10", "3.11"]
+

Evidence

The workflow explicitly runs 3.9, while project metadata declares Python >=3.10 and lists 3.10+
classifiers, creating a support/CI mismatch.

.github/workflows/python-package.yml[18-20]
pyproject.toml[5-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The GitHub Actions matrix runs on Python 3.9, but the project metadata declares `requires-python = ">=3.10"`. This makes CI coverage inconsistent with the project’s declared support policy.

### Issue Context
`pyproject.toml` is the authoritative source for supported Python versions.

### Fix Focus Areas
- .github/workflows/python-package.yml[18-20]
- pyproject.toml[5-21]

### Suggested fix
- Remove `3.9` from the matrix.
- Optionally expand the matrix to include the versions you claim in classifiers (e.g., add 3.12/3.13) if you intend to support them.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Compliance rules (platform): 19 rules

✅ Skills: fitbit2garmin-validate-output

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

2. Unpinned/outdated gh actions 🐞 Bug ⛨ Security

The workflow uses mutable tag references for actions (e.g., checkout@v4 and setup-python@v3), which
increases supply-chain risk and reduces build reproducibility. setup-python@v3 is also behind
current major releases, missing fixes and improvements.

Agent Prompt

### Issue description
The workflow references GitHub Actions by mutable tags (e.g., `@v4`, `@v3`) rather than immutable commit SHAs, and uses an older major version of `actions/setup-python`.

### Issue Context
Mutable tags can move over time, changing what code executes in CI.

### Fix Focus Areas
- .github/workflows/python-package.yml[22-26]

### Suggested fix
- Upgrade `actions/setup-python` to a current major version.
- Pin third-party actions to commit SHAs (optionally keep the tag in a comment) and use Dependabot to keep pins updated.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

3. Flake8 not enforced 🐞 Bug ⚙ Maintainability

The second flake8 invocation uses --exit-zero, so most lint violations won’t fail CI and the "Lint"
step won’t enforce style/complexity constraints. Only the first, select-limited flake8 command can
fail the build.

Agent Prompt

### Issue description
The workflow’s flake8 step uses `--exit-zero`, which forces success even when lint violations are found.

### Issue Context
The first flake8 command only checks a narrow set of error codes; the second command is where broader lint rules would normally be enforced.

### Fix Focus Areas
- .github/workflows/python-package.yml[32-37]

### Suggested fix
- Remove `--exit-zero` so lint violations fail the job, OR rename/split the step to clearly indicate that the second pass is advisory (e.g., upload as annotations) if non-blocking lint is intended.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

4. Package not installed in ci 🐞 Bug ☼ Reliability

The workflow installs tools and requirements.txt but never installs the project itself, so CI won’t
catch packaging issues (missing files in the wheel/sdist, dependency metadata drift, or the
console-script entry point). This can allow releases that pass tests from a checkout but fail when
installed by users.

Agent Prompt

### Issue description
CI runs pytest from the checked-out source tree without ever installing the project. This skips validation of packaging metadata and entry points.

### Issue Context
The project declares a console script (`fitbit2garmin`) in `pyproject.toml`, which should be validated as part of CI.

### Fix Focus Areas
- .github/workflows/python-package.yml[27-31]
- pyproject.toml[5-34]

### Suggested fix
- After installing dependencies, run one of:
  - `python -m pip install -e .` (editable)
  - or build and install a wheel in a clean env for stronger validation.
- Prefer installing dependencies from the project metadata (e.g., `pip install .`) rather than maintaining a separate requirements.txt as the single source of truth (unless requirements.txt is intentionally the canonical lock/source).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools