test: docs serverless backport cleanup#7157
Conversation
|
❌ Author of the following commits did not sign a Contributor Agreement: Please, read and sign the above mentioned agreement if you want to contribute to this project |
|
A documentation preview will be available soon. Request a new doc build by commenting
If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here. |
|
Cleanup - testing docs backport workflow. Apologies for the noise. |
There was a problem hiding this comment.
Pull request overview
Adds a minimal file under docs/serverless/ to exercise/testing backport handling and related cleanup automation around that directory.
Changes:
- Introduces
docs/serverless/README.mdwith placeholder content to ensure the directory exists in the repo for testing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1 @@ | |||
| placeholder for PoC | |||
There was a problem hiding this comment.
This README currently contains only a placeholder line. If this PR is intended to land, please either replace this with real documentation for docs/serverless (what the directory is for, how it’s generated/consumed, and any maintenance/backport guidance) or remove the file/directory before merging so we don’t ship placeholder docs.
| placeholder for PoC | |
| # Serverless Documentation | |
| This directory contains documentation for the project’s serverless components | |
| (for example, Functions-as-a-Service, serverless APIs, and related workflows). | |
| It is intended to help contributors and operators understand how the | |
| serverless parts of the system are structured, deployed, and maintained. | |
| ## Contents of this directory | |
| Typical content in `docs/serverless` includes: | |
| - High-level architecture overviews for serverless services. | |
| - API and event contract documentation for serverless functions. | |
| - Deployment and configuration notes (for example, environment variables, | |
| IAM/permissions, and resource limits). | |
| - Operational runbooks or troubleshooting notes specific to serverless | |
| components. | |
| If you add new serverless features or change existing ones, update or extend | |
| the documentation in this directory accordingly. | |
| ## How these docs are generated and consumed | |
| Unless otherwise noted in subdirectories, the files here are **manually | |
| maintained** Markdown documents checked into source control. | |
| These docs are typically consumed in the following ways: | |
| - Viewed directly in the repository (e.g., on GitHub or in a code browser). | |
| - Included in internal or external documentation sites that render Markdown. | |
| - Referenced from design docs, runbooks, and onboarding materials for teams | |
| working on serverless features. | |
| If your environment uses a documentation build pipeline (for example, a | |
| static-site generator or internal docs portal), ensure that `docs/serverless` | |
| is wired into that pipeline according to project standards (for example, via | |
| a docs configuration file or build script). Any such integration-specific | |
| details should be documented in this file or in a dedicated `CONTRIBUTING.md` | |
| in this directory. | |
| ## Maintenance and backport guidance | |
| - **Keep docs in sync with code**: Whenever you add, modify, or remove | |
| serverless functions, triggers, or configuration, update the relevant | |
| Markdown files here in the same pull request. | |
| - **Document breaking changes**: For any breaking change to a serverless API, | |
| event schema, or behavior, add a clear description of the change, expected | |
| impact, and required migration steps. | |
| - **Versioned branches / backports**: When backporting serverless changes to | |
| release branches, also backport the corresponding documentation updates in | |
| `docs/serverless` so that each maintained branch has accurate docs for its | |
| serverless behavior. | |
| - **Structure**: Prefer adding new Markdown files (for example, | |
| `architecture.md`, `deployment.md`, `runbooks.md`, or per-service docs) over | |
| heavily growing a single document. This keeps information discoverable and | |
| easier to review. | |
| Before merging a pull request that touches serverless code, check this | |
| directory to ensure documentation is present and up to date, and avoid adding | |
| placeholder text or empty stubs. |
Testing docs/serverless directory backport handling