Skip to content

Develop - #92

Closed
MarTrepodi wants to merge 7 commits into
mainfrom
develop
Closed

Develop#92
MarTrepodi wants to merge 7 commits into
mainfrom
develop

Conversation

@MarTrepodi

Copy link
Copy Markdown
Collaborator

Description

Related Issues

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Refactor (code change that neither fixes a bug nor adds a feature)
  • Documentation
  • Tests

Checklist

  • My commits follow the Angular commit convention (feat:, fix:, refactor:, etc.)
  • I have added/updated docstrings with type hints for any new or changed public methods
  • I have added unit tests that cover my changes (mocked, not requiring a live comlink service)
  • All existing tests still pass (python -m pytest tests/ -v)
  • Ruff linter passes (ruff check src/ tests/)
  • I have not bundled unrelated changes in this PR

Testing

MarTrepodi and others added 7 commits May 9, 2026 19:36
## 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>
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 MarTrepodi self-assigned this May 15, 2026
@MarTrepodi MarTrepodi added the code maintenance General code housekeeping items label May 15, 2026
@MarTrepodi
MarTrepodi enabled auto-merge (squash) May 15, 2026 13:28
@MarTrepodi MarTrepodi closed this May 15, 2026
auto-merge was automatically disabled May 15, 2026 13:30

Pull request was closed

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

Labels

code maintenance General code housekeeping items

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant