spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

ci: re-activate the integration-tests job when new CI hardware arrives #461

New Issue
Open
opened 2026-07-08 21:28:31 +00:00 by spikerj · 1 comment
spikerj commented 2026-07-08 21:28:31 +00:00
Owner
Copy Link
Copy Source

Follow-up to #444.

The integration-tests job in spikersoft-backend .gitea/workflows/tests.yml was rewritten for the modernized Testcontainers-based suite (no compose orchestration — fixtures start their own Mongo 8 / delayed-message RabbitMQ / Redis containers), but it is deliberately deactivated: current CI hardware is overtaxed, new servers are expected soon.

Current state:

  • Job runs only on manual workflow_dispatch with the run_integration_tests input set to true (default false).
  • Suite is green and has since been expanded under #465: 166 passed / 0 failed / 0 skipped, ~5m19s locally under the Release invocation (was 100 / 3 skipped at filing; spikersoft-backend PR #167 + follow-ups, then PRs #189–#196).

To re-activate (once the new servers land)

  • Confirm the runner has Docker available (docker info) and can pull the pinned images: redis:8 (digest-pinned per #462, ~200 MB), mongo:8, RabbitMQ delayed-message image
  • Do a manual workflow_dispatch run with run_integration_tests=true to validate on the new hardware
  • Flip the run_integration_tests input default back to 'true'
  • Re-add the master-push condition to the job if: (github.event_name == 'push' && github.ref == 'refs/heads/master' || ...) — initially non-blocking per #444
  • Once stable, consider adding it to master branch protection as a required check

Repo: spikersoft-backend · see .gitea/workflows/tests.yml comments and SpikerSoft.Tests.Integration/README.md § CI.

Follow-up to #444. The `integration-tests` job in spikersoft-backend `.gitea/workflows/tests.yml` was rewritten for the modernized Testcontainers-based suite (no compose orchestration — fixtures start their own Mongo 8 / delayed-message RabbitMQ / Redis containers), but it is **deliberately deactivated**: current CI hardware is overtaxed, new servers are expected soon. Current state: - Job runs only on manual `workflow_dispatch` with the `run_integration_tests` input set to `true` (default `false`). - Suite is green and has since been expanded under #465: **166 passed / 0 failed / 0 skipped**, ~5m19s locally under the Release invocation (was 100 / 3 skipped at filing; spikersoft-backend PR #167 + follow-ups, then PRs #189–#196). ## To re-activate (once the new servers land) - [ ] Confirm the runner has Docker available (`docker info`) and can pull the pinned images: `redis:8` (digest-pinned per #462, ~200 MB), `mongo:8`, RabbitMQ delayed-message image - [ ] Do a manual `workflow_dispatch` run with `run_integration_tests=true` to validate on the new hardware - [ ] Flip the `run_integration_tests` input default back to `'true'` - [ ] Re-add the master-push condition to the job `if:` (`github.event_name == 'push' && github.ref == 'refs/heads/master' || ...`) — initially non-blocking per #444 - [ ] Once stable, consider adding it to master branch protection as a required check Repo: spikersoft-backend · see `.gitea/workflows/tests.yml` comments and `SpikerSoft.Tests.Integration/README.md` § CI.
spikerj commented 2026-07-09 02:27:03 +00:00
Author
Owner
Copy Link
Copy Source

Status update from the coverage-expansion work (#465, now complete): the integration suite has grown from 100 to 166 tests and is verified ready for CI re-activation whenever the hardware lands.

Verified locally with the exact invocation from .gitea/workflows/tests.yml (dotnet build SpikerSoft.sln --configuration Release then dotnet test SpikerSoft.Tests.Integration/... --no-build --configuration Release):

  • 166 passed / 0 failed / 0 skipped, duration 5m19s on a dev box
  • No external network beyond Docker image pulls; all images now digest-pinned (redis:8 migration per #462, Mongo/RabbitMQ already pinned)
  • No model weights or GPU needed — new areas (art pipe messaging, safety RPC, GPU leases, quiz generation, book upload) run against real Testcontainers brokers/stores with only executors/classifiers/LLMs faked
  • The three long-standing Skip="Requires actual PDF file and AI model" tests were replaced with real coverage, so the suite now has zero skips
  • #450 teardown ordering preserved (in-process hosts stop before containers)

Note: the run is slightly over the old ~5-minute mark now (5m19s Release, ~5m Debug) purely from the added coverage; individual fixtures still start in parallel and nothing waits on external services.

CI defaults remain off per this ticket — no workflow changes made. When new servers arrive, the re-activation path documented in the workflow comment still applies: run workflow_dispatch with run_integration_tests=true to validate the runner, then flip the default and restore the master-push condition.

Status update from the coverage-expansion work (#465, now complete): the integration suite has grown from 100 to **166 tests** and is verified ready for CI re-activation whenever the hardware lands. Verified locally with the exact invocation from `.gitea/workflows/tests.yml` (`dotnet build SpikerSoft.sln --configuration Release` then `dotnet test SpikerSoft.Tests.Integration/... --no-build --configuration Release`): - **166 passed / 0 failed / 0 skipped**, duration 5m19s on a dev box - No external network beyond Docker image pulls; all images now digest-pinned (`redis:8` migration per #462, Mongo/RabbitMQ already pinned) - No model weights or GPU needed — new areas (art pipe messaging, safety RPC, GPU leases, quiz generation, book upload) run against real Testcontainers brokers/stores with only executors/classifiers/LLMs faked - The three long-standing `Skip="Requires actual PDF file and AI model"` tests were replaced with real coverage, so the suite now has **zero skips** - #450 teardown ordering preserved (in-process hosts stop before containers) Note: the run is slightly over the old ~5-minute mark now (5m19s Release, ~5m Debug) purely from the added coverage; individual fixtures still start in parallel and nothing waits on external services. CI defaults remain off per this ticket — no workflow changes made. When new servers arrive, the re-activation path documented in the workflow comment still applies: run `workflow_dispatch` with `run_integration_tests=true` to validate the runner, then flip the default and restore the master-push condition.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#461