Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/content/contributing/contributing-docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -605,7 +605,8 @@ As a docs approver or maintainer, you need to perform routine **upmerges** to ke
1. Follow the ready-for-review `upmerge/` pull request linked by the **Create pull request** step. If merging produces no net changes, including when the source is already an ancestor of `edge`, no PR is created. Genuine content conflicts instead stop the run and list the affected files; no provisional source snapshot or draft PR is created.
1. Review the diff, including the Docsy module version in `docs/go.mod` and its checksum entries in `docs/go.sum`. If versions differ, keep the `edge` Docsy version and corresponding checksum entries unless the PR includes an intentional, reviewed Docsy version change. Retain unrelated module changes rather than restoring either file wholesale. The workflow preserves the `edge` versions of `docs/config.toml` and `docs/layouts/partials/hooks/body-end.html`, including files deleted on `edge`.
1. If the workflow reports content conflicts, resolve them on the source or `edge` branch through normal review, preserving changes from both branches, then rerun to pick up fixes from either branch. Commits pushed after an attempt fetches its inputs are picked up by the next attempt. Keep resolution commits signed and DCO-signed-off. An older draft produced before this policy contains a provisional source snapshot, **not a resolved merge**; restore any omitted edge-only content before marking it ready.
1. Obtain the normal reviews and required checks, then squash-merge the PR. The workflow never bypasses branch rules or merges automatically.
If the resolution merges `edge` into the release branch, use **Create a merge commit** for that resolution PR, not squash or rebase. The merge ancestry is part of the fix: squashing can leave the same conflicts even when the resolved file contents are correct. Preserve the release-specific configuration and validate the resulting history with `git merge-tree --write-tree origin/edge HEAD` after fetching `edge`; it must exit successfully without conflicts.
1. Obtain the normal reviews and required checks, then squash-merge the generated `upmerge/` PR into `edge`. The workflow never bypasses branch rules or merges automatically.

The local `.github/workflows/upmerge.yaml` is a synced caller for the [shared upmerge workflow](https://github.com/radius-project/.github/blob/main/.github/workflows/__upmerge.yml). Docs and samples use that same implementation at `main`; only repository-specific settings, such as the docs files preserved from `edge`, belong in the caller.

Expand Down
Loading