Let docs-publish build both staging and prod, and dispatch to docs-publish - #126
Merged
Conversation
Adds a build-both workflow_dispatch input. prepare-ref-env now outputs a list of independent builds (each with its own build-ref) instead of one shared build-ref plus an environments label array, so trigger-generate-html can dispatch docs-generate-html.yml once per build - still fully separate runs, so no artifact-naming changes needed anywhere.
Drops the manual target-env/build-both input entirely - dispatching from the dev branch already gives staging-only, and dispatching from anything else already gives both, with no input needed. Only a change on the dev branch is known for certain not to affect prod, so every other trigger rebuilds both rather than trying to detect which one "actually changed".
Mirrors the pattern already working in docs-aura's docs-generate-html.yml (peter-evans/repository-dispatch to docs-publish), minus the matrix - this workflow already runs once per environment via docs-publish.yml's per-build dispatch loop. Sends dispatch-env (dev/prod) as publish_env, matching what docs-publish's check-build-branch step expects.
docs-generate-html.yml derives publish-env itself from build-ref against its own vars.DOCS_PROD_BRANCH, the same pattern already used elsewhere in this session - removes the need for docs-publish.yml to compute and pass it through, so that input is dropped entirely.
…ch case Deriving publish-env from build-ref alone breaks when DOCS_DEV_BRANCH == DOCS_PROD_BRANCH: docs-publish.yml dispatches the same build-ref twice to get one dev-labeled and one prod-labeled run, and build-ref alone can't tell those two dispatches apart. dispatch-env is now optional (blank = derive from build-ref, as before) and docs-publish.yml only passes it explicitly in that one case. A new resolve-env job derives both dispatch-env and publish-env from the same resolved value once, so an explicit override correctly overrides both rather than just one.
reusable-docs-build.yml was the only place using staging/prod - every other part of the publish pipeline (docs-publish's vars, dispatch-env, DOCS_DEV_BRANCH/DOCS_PROD_BRANCH) already speaks dev/prod. No caller (docs-aura, docs-http-api, docs-dataflow-connector) passes the literal string 'staging' explicitly - confirmed via search - so this only changes the default value, not any caller's actual behavior.
Now that reusable-docs-build.yml's publish-env speaks the same dev/prod vocabulary as dispatch-env, they were fully redundant - one value now feeds both, removing the duplicate output and the now-stale comments explaining the vocabulary split.
Not the only valid wiring: a repo with clean separate dev/main branches should give docs-generate-html.yml its own direct per-branch push trigger instead (docs-aura's existing pattern) - never build both environments from one commit when they're genuinely separate content.
dispatch-env and publish-env were the same value under two different names once the vocabulary was unified - reusable-docs-build.yml's input and the docs-publish payload were already publish-env/publish_env, so docs-generate-html.yml's own input was the odd one out.
Collaborator
|
Thanks for the documentation updates. The preview documentation has now been torn down - reopening this PR will republish it. |
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.
Summary
docs-publish.yml'sprepare-ref-envjob now resolves a list of independent builds ({buildRef, dispatchEnv, publishEnv}) instead of one sharedbuild-refplus anenvironmentslabel array.trigger-generate-htmldispatchesdocs-generate-html.ymlonce per build in that list - each remains a fully independent workflow run (not a matrix in one run), so no artifact-name collisions and no changes needed inreusable-docs-build.yml/reusable-docs-verify.yml.docs-generate-html.ymlgains apublish-htmljob that dispatches apublish-htmlevent to thedocs-publishrepo viapeer-evans/repository-dispatch, mirroring the pattern already live in docs-aura's copy of this workflow. This was previously missing entirely - the sandbox harness built and verified HTML but never handed off to publish.Test plan
docs-publish.ymlfrom a non-dev branch with no separatePROD_BRANCHconfigured - confirmed exactly one build resolves (staging), matching the "nothing to double up" case.PROD_BRANCHand a matching deployment-branch-policy entry to exercise the two-build path - confirmed two independentdocs-generate-html.ymlruns are triggered (one dev/staging, one prod), each completing with its own normally-named artifacts (no collisions, since they're separate runs). Test-only config reverted afterward.publish-htmljob successfully dispatches todocs-publish, and thatdocs-publish's owncheck-build-branchstep safely rejects it end-to-end (docs-tools has novars.DOCS_DEV_BRANCH/DOCS_PROD_BRANCHconfigured, so nothing actually gets published from this sandbox run).