chore(release): merge develop into main for the next release by MarTrepodi · Pull Request #90 · swgoh-utils/comlink-python

MarTrepodi · 2026-05-10T13:26:05Z

Draft release PR — promotes the current develop tip to main. Once merged, dispatch the comlink-python release workflow from main to bump the version, regenerate CHANGELOG.md, tag, and publish to PyPI via OIDC.

Contents — 6 commits since `v2.0.7`

75feb67 fix(tests): switch HMAC rejection tests from GET to POST endpoint (#89)
c9e3f59 fix(helpers): ensure arena payout time adjusts correctly when shifted to past
e8a6e05 fix(helpers): handle multi-day offsets in get_arena_payout
51235c1 chore(dependabot): set target branch to `develop`, limit open PRs to 10
8c0aa3a ci(release): guard release workflow against non-main dispatch (#86)
523a2ca ci: align workflow triggers with develop branch model (#85)

What's in this release

Bug fixes

get_arena_payout returns past datetime when offset spans more than one day (#87) — if → while so payouts shifted into the past by 24+ hour offsets advance day-by-day until landing in the future.

CI / infrastructure

Workflow triggers aligned with the new develop-based branch model (#85) — ci.yml, commitlint.yml, and integration.yml now run on [main, develop] PRs and pushes; stale references to 1.0-maintenance and 2.0-development removed; redundant test.yml deleted.
Release workflow hardened with a branch guard (#86) — both jobs in release.yml now require github.ref == 'refs/heads/main', preventing accidental dispatch from develop or feature branches.
HMAC integration tests fixed (#89) — rejection tests now call a POST endpoint (/playerArena) instead of /enums (GET, which the server doesn't HMAC-protect).

Chore

Dependabot configuration (commit 51235c1) — target-branch: develop and open-pull-requests-limit: 10 for the pip ecosystem.

No user-facing API changes

All changes are internal: bug fix in a helper, CI/test changes, dependabot config. No new methods, no signature changes, no removals.

Release plan

After this PR merges:

Trigger comlink-python release workflow from main: gh workflow run release.yml --ref main.
Workflow performs (gated by the new branch guard from ci(release): guard release workflow against non-main dispatch #86):
- uvx hatch version minor → 2.0.7 → 2.1.0
- uvx git-changelog regenerates CHANGELOG.md from commit history (Angular convention, semver)
- Commit + tag (v2.1.0) + push
- uvx hatch build (sdist + wheel)
- Publish to PyPI via Trusted Publishing OIDC (pypa/gh-action-pypi-publish SHA-pinned at v1.13.0)
GitHub auto-creates a release from the tag.

Test plan

All required CI checks pass on this PR (Lint, Type Check, Test (Python 3.10..3.13), Docs, Build, Validate Commit Messages, Integration Tests).
Merge method: rebase (not squash) to preserve the individual PR commits on main's linear history.
After merge, dispatch release.yml from main and verify:
- Version bumps to 2.1.0 in src/swgoh_comlink/version.py.
- CHANGELOG.md gets a new ## [v2.1.0] section.
- PyPI receives the new release.
- GitHub Release is auto-created.

Notes

This is a draft PR because the release cadence is your call — mark ready for review when you're prepared to cut v2.1.0.
Branch protection on main currently has contexts: [] (no required checks). Consider applying the required-contexts list documented in workflow-review-plan.md once stable.

Generated with Claude Code

## Summary - Replace stale branch references (`1.0-maintenance`, `2.0-development`) with `develop` in `ci.yml`, `commitlint.yml`, and `integration.yml`. - Add `develop` to push triggers in `ci.yml` and `integration.yml` so post-merge signal is visible on the integration branch. - Drop `async` and `statcalc` from `commitlint.yml` `scope-enum` (the underlying feature branches are deleted). - Delete `test.yml` since it is a strict subset of the `test` and `docs` jobs in `ci.yml` at lower fidelity (single Python version, no coverage). ## Why The repository moved to a `main` (release-only) + `develop` (integration) branch model. CI workflows still triggered on the previous `2.0-development` and `1.0-maintenance` names and never ran on `develop` itself — so PRs targeting `develop` got no checks and merges to `develop` had no post-merge verification. This is PR 1 of a two-PR plan from `workflow-review-plan.md`. PR 2 hardens `release.yml` with a branch guard. ## Test plan - [ ] `Lint`, `Type Check`, `Test (Python 3.10..3.13)`, `Docs`, `Build`, `Validate Commit Messages` all run on this PR (proves the new `develop` triggers fire). - [ ] No remaining stale branch references: `grep -rn "1.0-maintenance\|2.0-development\|2.0-auth\|feature/async\|feature/StatCalc" .github/` returns empty. - [ ] After merge, `Lint` etc. run on the develop branch tip (proves the push trigger fires). - [ ] Once merged and job names are stable, set required status checks on `main` per `workflow-review-plan.md`. ## Notes for reviewers - `test.yml` deletion is safe — branch protection on `main` currently has `contexts: []`, so it is not a required check anywhere. - `labeler.yml` was intentionally not touched: it triggers on PR open/sync with no branch list, which is correct. - `release.yml` branch guard is deliberately deferred to a follow-up PR (different risk profile, needs manual dispatch test). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

## Summary Add `if: github.ref == 'refs/heads/main'` to both jobs in `release.yml` so that an accidental `workflow_dispatch` from `develop` or a feature branch exits without bumping the version, tagging, or publishing to PyPI. ## Why `release.yml` currently only has `on: workflow_dispatch:` with no branch restriction. With the new branch model (`develop` for integration, `main` for releases only), it would be easy to dispatch the release workflow from `develop` and accidentally cut a release from un-merged integration work. The guard is applied per-job because workflow-level `if:` is not valid for `workflow_dispatch`. ## Why not migrate to tag-based triggers The original review document suggested replacing `workflow_dispatch` with `on: push: tags: ['v*']`. That is correct for workflows that publish in *response* to tags created elsewhere, but this workflow *creates* the tag itself (line 54: `git tag -a "v$VERSION"` and `git push --follow-tags`). Reacting to its own tag would be circular, or require splitting the tag-creation step out into a separate workflow without meaningful benefit. The dispatch-with-guard pattern is the right fit. ## Test plan - [ ] After merge, dispatch from a non-main branch: `gh workflow run release.yml --ref <feature-branch>` — every job should be skipped (`if` evaluates false). - [ ] Dispatch from `main` should run normally (do not test the publish path until ready for an actual release; consider commenting out the `pypi-publish` step in a fork first if a smoke test is desired). - [ ] No regression to the `on: workflow_dispatch:` trigger itself — the workflow still appears in the GitHub Actions UI and accepts manual dispatch. ## Notes - Action `uses:` lines are intentionally not pinned to SHA in this PR. The repository already configures Dependabot for `github-actions` with `target-branch: develop`, which will pin to SHA organically over the next several update cycles. - Independent of [#85](#85) (the trigger-alignment PR). Either order of merge works. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Replace the single if-check with a while-loop so that payouts shifted into the past by offsets of 24+ hours are advanced day-by-day until they land in the future. Before this fix, calling get_arena_payout(offset=1440) when the wall clock was past the configured payout hour would return today at 18:00 (squad) or 19:00 (fleet), a time already in the past, violating the documented contract that the result is always in the future. The TestGetArenaPayoutEdge.test_payout_already_passed_adds_day test covers this case and now passes regardless of time of day. Fixes #87 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… to past

Closes #88 ## Summary The four HMAC rejection tests in `tests/integration/test_hmac.py` (`test_hmac_no_key_rejected`, `test_hmac_wrong_key_rejected`, and their async variants) were calling `client.get_enums()`, which is a **GET** request to `/enums`. The Comlink HMAC service does not enforce HMAC on GET endpoints — only on POST — so the server returned 200 OK regardless of authentication and the expected `SwgohComlinkException` was never raised. All four tests failed with `Failed: DID NOT RAISE`. This PR switches those tests to call `client.get_player_arena(allycode=TEST_ALLYCODE, player_details_only=True)`, a POST request to `/playerArena` (HMAC-protected). Uses the shared `TEST_ALLYCODE` constant from `conftest.py` so the rejection tests align with the existing `get_player` and `get_player_arena` success tests. ## Why this only surfaced now Integration tests never ran on PRs targeting `develop` until [#85](#85) landed and `integration.yml` started triggering on `develop` PRs. PRs to `main` had been skipping these tests because `develop` was not in the trigger list, so the latent bug went unnoticed. ## Verification Probed a live HMAC-protected Comlink container directly to confirm the diagnosis and exercised the new test code end-to-end: | Scenario | Endpoint | Result | |---|---|---| | no auth | `GET /enums` | 200 OK *(server doesn't protect GET — root cause)* | | no auth | `POST /playerArena` | 403 `HMACValidationError` (Authorization header missing) | | wrong secret | `POST /playerArena` | 403 `HMACValidationError` (HMAC validation failed) | | valid `test_key`/`test_secret` | `POST /playerArena` | 200 OK with real `playerDetailsOnly` response | All four updated tests `PASS` against the live container. ## Test plan - [ ] CI Integration Tests check passes on this PR (was failing on every PR since #85 merged due to this bug). - [ ] Other CI checks (`Lint`, `Type Check`, `Test (Python 3.10..3.13)`, `Docs`, `Build`, `Validate Commit Messages`) remain green. - [ ] No changes outside `tests/integration/test_hmac.py`; client and server code untouched. ## Notes - Production HMAC client behavior is correct and unchanged — verified by the existing `test_hmac_*_request_succeeds` tests (which continue to pass) and by the positive-control valid-auth probe in this PR's verification. - Bug was purely in test scaffolding. Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

PR #90 squash-merged develop's 6 commits into a single commit on main, leaving develop's original commits as a divergent history. This merge brings main's squash and the subsequent urllib3 bump (#91) into develop so develop and main share a common tip again.

MarTrepodi and others added 6 commits May 9, 2026 19:36

chore(dependabot): set target branch to develop, limit open PRs to 10

51235c1

fix(helpers): ensure arena payout time adjusts correctly when shifted…

c9e3f59

… to past

github-actions Bot added ci Changes related to continuous integration processes code testing labels May 10, 2026

MarTrepodi self-assigned this May 10, 2026

MarTrepodi marked this pull request as ready for review May 11, 2026 20:14

MarTrepodi merged commit 904a973 into main May 11, 2026
27 checks passed

Navigation Menu

Uh oh!

chore(release): merge develop into main for the next release - #90

chore(release): merge develop into main for the next release#90
MarTrepodi merged 6 commits into
mainfrom
develop

MarTrepodi commented May 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MarTrepodi commented May 10, 2026

Contents — 6 commits since v2.0.7

What's in this release

Bug fixes

CI / infrastructure

Chore

No user-facing API changes

Release plan

Test plan

Notes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Contents — 6 commits since `v2.0.7`