fix: sha256:4c406127fd42cddb7bd2282519704e86a5ed7129fe2682617e23821e2bddb259 · gabriel/musehub

fix: publish_muse_release.sh failed against production on two counts

Discovered live while publishing muse 0.2.1rc4 to production:

1. Every aws ssm call had no --profile at all, so it silently ran under the ambient default credentials (musehub-infra, the Nonproduction account) regardless of $ENV. Production's instance lives in a separate AWS account with no static IAM user by design -- the resulting error, 'InvalidInstanceId ... not in a valid state for account', looks like a broken instance rather than a missing --profile. Fixed by resolving PROFILE_ARGS per environment (empty for staging, --profile musehub-production for production) and applying it to every aws ssm send-command/get-command-invocation call. S3 calls deliberately keep using the ambient default credentials in both cases -- the release bucket is a single shared, public-read bucket, not per-environment.

2. Once (1) was fixed and the SSM call reached the right account, the remote command's own `aws s3 cp` (authenticated via the production instance's IAM role) got '403 Forbidden' on HeadObject -- confirmed via direct diagnostics on the instance that an anonymous curl and `aws s3 cp --no-sign-request` both succeeded (200 OK) while the signed request using the instance role did not. An explicit IAM deny (an account-level guardrail) overrides the bucket's public Allow for authenticated principals; anonymous requests never touch IAM at all. Fixed by adding --no-sign-request to the remote download, matching how install.sh itself fetches releases over plain HTTPS with no credentials -- the bucket is deliberately public-read, so there was never a reason to authenticate for this GET in the first place.

Tests: tests/test_deployment.py::TestPublishMuseReleaseProfile -- five tests: PROFILE_ARGS resolves correctly per environment (extracted via the real case-statement source, executed in a subprocess), every aws ssm call site actually passes "${PROFILE_ARGS[@]}" (regex count match, guards against a new call site being added without it), S3 calls never use it, and the remote CMD's aws s3 cp includes --no-sign-request. Full tests/test_deployment.py sweep: 42 passed.

Verified for real, not just via tests: reran the actual publish against production after each fix -- first attempt failed with the account error, second with the 403, third (both fixes applied) succeeded end to end including all 20 smoke_muse.sh checks against https://musehub.ai. muse 0.2.1rc4 is now live on both staging and production.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

symbols added

files changed

1075

files in snapshot

dead code introduced

Semantic Changes 9 symbols

~ deploy/publish_muse_release.sh .sh

~ tests/test_deployment.py .py 9 symbols added

+ TestPublishMuseReleaseProfile class class TestPublishMuseReleaseProfile L520–601

+ _extract_env_block method method _extract_env_block L531–541

+ _resolve_profile_args method method _resolve_profile_args L543–554

+ test_every_ssm_call_site_passes_profile_args method method test_every_ssm_call_site_passes_profile_args L565–577

+ test_production_resolves_musehub_production_profile method method test_production_resolves_musehub_production_profile L556–557

+ test_remote_download_uses_no_sign_request method method test_remote_download_uses_no_sign_request L589–601

+ test_s3_calls_do_not_use_profile_args method method test_s3_calls_do_not_use_profile_args L579–587

+ test_staging_resolves_no_profile method method test_staging_resolves_no_profile L559–563

+ _PUBLISH_MUSE_RELEASE_SH variable variable _PUBLISH_MUSE_RELEASE_SH L29–29

Files Changed

1075 in snapshot

~ deploy/publish_muse_release.sh .sh

~ tests/test_deployment.py .py

← Older Oldest on fix/publish-muse-release-production-auth

All commits

Newer → Latest on fix/publish-muse-release-production-auth

0 comments

No comments yet. Be the first to start the discussion.

To add a comment, use the Muse CLI: muse hub commit comment sha256:4c406127fd42cddb7bd2282519704e86a5ed7129fe2682617e23821e2bddb259 --body "your comment"