ci: split marketplace publish into explicit staging + production workflows#20
Merged
Merged
Conversation
…flows Replaces the single publish.yml (which used an ambiguous `vars.OS_CLOUD_URL`, so a dispatch could silently target the wrong cloud) with two explicit, hard-coded-target workflows: - publish-staging.yml → https://cloud.objectos.app (environment: staging) Triggers: workflow_dispatch + release published (auto-publish to staging). - publish-production.yml → https://cloud.objectos.ai (environment: production) MANUAL ONLY (workflow_dispatch). No release/push trigger — production is a deliberate promotion. Use the `production` GitHub Environment's required- reviewers protection to gate it. Both reuse scripts/publish-template.mjs and resolve OS_CLOUD_API_KEY from their GitHub Environment (falls back to a repo-level secret of the same name). Removing the shared var eliminates the staging/prod target ambiguity. Setup note: create `staging` + `production` GitHub Environments in repo settings, each with an OS_CLOUD_API_KEY secret (+ required reviewers on production). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ents Simpler ops: drop the `environment:` scoping (which needs per-repo Environment setup) in favour of two distinctly-named secrets settable ONCE at the org level: - staging → OS_CLOUD_API_KEY_STAGING - production → OS_CLOUD_API_KEY_PRODUCTION URLs stay hard-coded (staging=cloud.objectos.app, prod=cloud.objectos.ai), so target + credential are both fully separated and a staging dispatch can never carry the prod key. Production remains manual-dispatch-only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Replaces the single
publish.yml(ambiguousvars.OS_CLOUD_URL) with two explicit, hard-coded-target workflows using distinct org-level secrets — no GitHub Environments, no per-repo setup.publish-staging.ymlhttps://cloud.objectos.appOS_CLOUD_API_KEY_STAGINGpublish-production.ymlhttps://cloud.objectos.aiOS_CLOUD_API_KEY_PRODUCTIONBoth reuse
scripts/publish-template.mjs. Target URL + credential are fully separated per environment, so a staging dispatch can never carry the prod key or hit the prod cloud.Setup — one-time, ORG level (Settings → Secrets and variables → Actions)
Add two organization secrets (shared by all repos, no per-repo config):
OS_CLOUD_API_KEY_STAGINGOS_CLOUD_API_KEY_PRODUCTIONFlow
Cut a release (or dispatch staging) → auto-publishes to staging → verify on cloud.objectos.app → dispatch production to promote.
Pairs with #19 (template version bumps for the 7.7.0 republish).