ci: replace stale ARGUS_STAGING_KEY with local cueapi-core in test job#32
Merged
govindkavaturi-art merged 2 commits intoMay 6, 2026
Conversation
… ARGUS_STAGING_KEY The `test` job's `pytest tests/` runs the SDK's CRUD tests against a real CueAPI server. Previously that server was remote staging, authenticated by `secrets.ARGUS_STAGING_KEY`. Argus was retired 2026-05-02 (cueapi PR #539) and that key/user is no longer valid — every PR's `test` job has been red for ~3 days with `AuthenticationError: Invalid API key`, blocking PRs #30 and #31 (and any future SDK PRs). This switches the job to the same self-contained pattern that's already proven by the passing `sdk-integration` job: clone cueapi-core, install, migrate, boot uvicorn locally, register a fresh test user via POST /v1/auth/register (gated by ALLOW_REGISTER=true), capture the key, plumb it through the existing `CUEAPI_STAGING_URL` / `CUEAPI_STAGING_API_KEY` env vars (no SDK code change needed — `tests/conftest.py` already reads them from env). Workflow-only diff. No SDK behavior change. Note: `notify-merge` still references `secrets.ARGUS_CUEAPI_KEY` for the post-merge prod telemetry cue. That key is also stale, but the step runs after auto-merge so it doesn't gate the PR — leaving for a follow-up that needs a new prod key minted by an operator. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…pi-core conftest) First push failed because OSS migration set ends at 023 while the User model declares an `api_key_encrypted` column with no migration backing it. That's a parity drift in cueapi-core (private migration 019 in the hosted repo includes the column; the OSS port renamed/replaced it with the alert-webhook bits but kept the column on the model). `alembic upgrade head` produced a schema missing that column → register endpoint 500'd on the User SELECT. Switch the CI bootstrap to model-driven schema init via `Base.metadata.create_all`, which is the exact pattern cueapi-core's own `tests/conftest.py` uses (and which is robust to model/migration drift because the model is the source of truth for tests). Imports the same model list as conftest so all tables register before create_all runs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
govindkavaturi-art
approved these changes
May 6, 2026
Member
govindkavaturi-art
left a comment
govindkavaturi-art
left a comment
There was a problem hiding this comment.
Right shape for post-Argus SDK testing: stand up cueapi-core locally instead of pointing at the retired ARGUS_STAGING_KEY. Schema init via Base.metadata.create_all mirrors cueapi-core's tests/conftest.py pattern. Approve.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
testjob infeature-to-main.ymlruns the SDK's CRUD tests (tests/test_cues.py,tests/test_webhook.py) against a real CueAPI server, authenticated bysecrets.ARGUS_STAGING_KEY. That key has been invalid for ~3 days — Argus was retired 2026-05-02 (cueapi#539) and the staging user/key was decommissioned.Symptom on PRs #30 and #31: every test that uses the
clientfixture errors withcueapi.exceptions.AuthenticationError: Invalid API key. Both PRs blocked.What
Switch
testto the same self-contained pattern already proven by the passingsdk-integrationjob:alembic upgrade headagainst the test Postgresapp.main:app) on127.0.0.1:8000in the background/health200 (30 s budget)POST /v1/auth/registerwith a unique-per-attempt email (ci-sdk-${RUN_ID}-${ATTEMPT}@example.com);ALLOW_REGISTER=truegates thisapi_keyfrom the JSON response, mask it, expose via step outputCUEAPI_STAGING_URL/CUEAPI_STAGING_API_KEYenv vars at local valuespytest tests/ -v --tb=shortexactly as beforetests/conftest.pyreads both env vars unchanged — no SDK code change needed.Scope / non-goals
feature-to-main.ymltestjob).notify-mergestill usessecrets.ARGUS_CUEAPI_KEYfor the post-merge telemetry cue againstapi.cueapi.ai. That key is also stale, but the step runs after auto-merge so it does not gate the PR. Leaving for a follow-up that needs a fresh prod key minted by an operator.sdk-integration.ymlchanges; that job already runs against a local in-process cueapi-core via httpx ASGI fixtures.Test plan
Feature PR to Main / testpasses on this PR (proves the new path)SDK Integration Tests / sdk-integrationcontinues passingtestjobs should now go greenOnce merged
feat(cues): client.cues.fire(send_at=...)) — rebase, will go greenfeat: add Execution / Worker / Agent / Message Pydantic models) — rebase, will go greenARGUS_CUEAPI_KEYinnotify-mergefor a fresh prod key (or remove the post-merge cue entirely)