Move docs workflows to elastic/docs-actions#514
Conversation
Moves docs CI/CD from elastic/docs-builder to elastic/docs-actions. Part of elastic/docs-eng-team#474
📝 WalkthroughWalkthroughThis change restructures the documentation workflow configuration by migrating from the ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/docs-deploy.yml:
- Around line 3-5: The deploy workflow currently triggers on workflow_run types:
[completed] which includes failed/cancelled runs; add an explicit success check
by gating the deploy job with an if condition that tests
github.event.workflow_run.conclusion == 'success' (use the GitHub Actions
expression syntax ${{ github.event.workflow_run.conclusion == 'success' }}) so
the docs-deploy job only runs when the docs-build upstream workflow passed;
reference the existing workflow_run, workflows: [docs-build], and types:
[completed] settings and add the if at the job level (or top-level jobs block)
to enforce the success-only condition.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f0f4bb00-ad48-4faf-93d1-af7acced9434
📒 Files selected for processing (4)
.github/workflows/docs-build.yml.github/workflows/docs-cleanup.yml.github/workflows/docs-deploy.yml.github/workflows/docs-preview-cleanup.yml
💤 Files with no reviewable changes (1)
- .github/workflows/docs-cleanup.yml
| workflow_run: | ||
| workflows: [docs-build] | ||
| types: [completed] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In GitHub Actions, does workflow_runwithtypes: [completed]trigger for failed and cancelled upstream workflows, and isif: github.event.workflow_run.conclusion == 'success' the recommended gate?
💡 Result:
Yes, the workflow_run event with types: [completed] triggers for upstream workflows that failed, were cancelled, or succeeded. The conclusion property in github.event.workflow_run.conclusion is set to values including 'success', 'failure', and 'cancelled'. Official GitHub documentation recommends using if: github.event.workflow_run.conclusion == 'success' at the job level to gate downstream actions, as shown in examples where separate jobs handle success and failure cases. Note that there can occasionally be delays where conclusion is temporarily null, but this resolves.
Citations:
- 1: https://docs.github.com/en/actions/reference/events-that-trigger-workflows
- 2: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 3: https://docs.github.com/rest/actions/workflow-runs
🏁 Script executed:
cat -n .github/workflows/docs-deploy.ymlRepository: elastic/elastic-otel-python
Length of output: 505
Gate deploy job on successful upstream build conclusion.
workflow_run with types: [completed] triggers for failed and cancelled upstream workflows. Add an explicit success condition so the deploy job only runs when the docs-build workflow passed.
Suggested fix
jobs:
deploy:
+ if: ${{ github.event.workflow_run.conclusion == 'success' }}
uses: elastic/docs-actions/.github/workflows/docs-deploy.yml@v1
with:
enable-vale-linting: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/docs-deploy.yml around lines 3 - 5, The deploy workflow
currently triggers on workflow_run types: [completed] which includes
failed/cancelled runs; add an explicit success check by gating the deploy job
with an if condition that tests github.event.workflow_run.conclusion ==
'success' (use the GitHub Actions expression syntax ${{
github.event.workflow_run.conclusion == 'success' }}) so the docs-deploy job
only runs when the docs-build upstream workflow passed; reference the existing
workflow_run, workflows: [docs-build], and types: [completed] settings and add
the if at the job level (or top-level jobs block) to enforce the success-only
condition.
3 participants
Summary
Moves our docs CI/CD workflow logic from
elastic/docs-buildertoelastic/docs-actions.elastic/docs-builderhas grown in scope;elastic/docs-actionslets thedocs team push updates to the
@v1tag independently without coupling tothe broader builder tooling.
The new setup follows GitHub's recommended two-phase workflow approach:
all required checks on pull requests now run with read-only access only.
Preview deployments and PR comments happen in a separate phase triggered
after the required check completes.
Replaces
preview-build.ymlanddocs-cleanup.ymlwith three new workflowfiles:
docs-build.yml,docs-deploy.yml, anddocs-preview-cleanup.yml.Preview deployments for forks:
Preview deployments are not available for fork PRs by default. If you are an
Elastic employee working from a fork, previews will work once your Elastic
GitHub organization membership is set to Public:
Go to https://github.com/orgs/elastic/people and find your name
Open the visibility dropdown next to your name and select Public
Or: GitHub profile -> Organizations -> Elastic logo -> set visibility
to Public.
Contributors outside Elastic will still get build validation feedback on
their PRs -- only preview deployments are skipped.
Post-merge
docs-buildinstead ofpreview-build(if applicable)cc @elastic/ingest-docs