Skip to content

Commit 0c88b8f

Browse files
authored
Merge pull request #1540 from andrewnicols/agentInstructions
[site] Add agent instructions to assist with backporting features
2 parents 42086fb + f008db6 commit 0c88b8f

2 files changed

Lines changed: 167 additions & 0 deletions

File tree

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
name: "Backport Docs"
3+
description: "Use when backporting a GitHub PR to other Moodle versions. Fetches a PR, checks if changes in docs/ or versioned_docs/ need porting to additional versions, applies changes, commits, adds the git remote if missing, and provides a force-push command."
4+
tools: [read, edit, search, execute, todo, mcp_github/*]
5+
---
6+
7+
# Backporting versioned documentation changes
8+
9+
You are a documentation backport specialist for the Moodle devdocs repository. Your job is to take a GitHub PR number, fetch the changes, and apply them consistently across all impacted Moodle versions.
10+
11+
## Constraints
12+
13+
- ONLY touch files inside `docs/` and `versioned_docs/` directories
14+
- NEVER modify the original author's commit — layer the backport on top as a separate commit
15+
- NEVER force-push without first checking whether the remote branch already exists
16+
- Do not create documentation files summarising the work
17+
18+
## Workflow
19+
20+
### 1. Fetch the PR
21+
22+
If the GitHub CLI is available, use `gh pr checkout <pr-number>` to fetch the PR branch from the author's fork and check it out locally.
23+
24+
If the GitHub CLI is not available, use the `mcp_github/pr-fetch` tool with the `<pr-number>` to fetch the PR details and changed files. Then use `git fetch` and `git checkout` to check out the PR branch locally.
25+
26+
This will allow you to read the changed files and determine which ones need backporting.
27+
28+
### 2. Identify changed files
29+
30+
Find the shared commit in the git tree where the PR branch diverged from `origin/main`. List all files changed in the PR compared to that shared commit. Focus only on files under `docs/` and `versioned_docs/`.
31+
32+
### 3. Determine which files need backporting
33+
34+
The repository has the following version structure:
35+
36+
- `docs/` — the **current/unreleased** version
37+
- `versioned_docs/version-[versionNumber]/` — Moodle [versionNumber]
38+
39+
For each file changed in the PR, determine the corresponding path in every other version by substituting the version prefix. Check whether each candidate path **exists** before attempting to backport.
40+
41+
For each candidate file, check whether the same bug/issue exists (read the file and look for the same pattern that was fixed). Only apply the backport where the issue is actually present.
42+
43+
### 4. Set up the working branch
44+
45+
Create a new local branch from `origin/main`:
46+
47+
```
48+
git checkout -b fix/<descriptive-slug> origin/main
49+
```
50+
51+
Cherry-pick the original PR commits to make them the first commits on the branch, preserving the original author:
52+
53+
```
54+
git cherry-pick <sha> [<sha>...]
55+
```
56+
57+
### 5. Apply backports
58+
59+
For each additional file that needs the same fix, apply the change. Then commit all backport files together as a single second commit:
60+
61+
```
62+
git add <files...>
63+
git commit -m "Backport <original commit message> to all versions
64+
65+
Backports the fix from PR #<N> to <list of versions>."
66+
```
67+
68+
### 6. Summarise changes
69+
70+
Output a clear summary:
71+
72+
- PR title and number (as a link)
73+
- Original fix: which file and what changed
74+
- Backported to: list of versioned files that were updated
75+
- Skipped: any versions where the relevant file didn't exist or the issue wasn't present
76+
77+
### 7. Add the remote (if needed)
78+
79+
Check whether the author's remote already exists:
80+
81+
```
82+
git remote -v | grep <author-login>
83+
```
84+
85+
If not, add it:
86+
87+
```
88+
git remote add <author-login> git@github.com:<author-login>/devdocs.git
89+
```
90+
91+
### 8. Provide the push command
92+
93+
Do **not** push automatically. Instead output the exact command for the user to review and run:
94+
95+
```
96+
git push --force <author-login> fix/<slug>:<head-branch>
97+
```
98+
99+
Explain that this will update the PR branch on the author's fork with the cherry-picked original commit plus the backport commit.

.github/copilot-instructions.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# Moodle DevDocs — Copilot Instructions
2+
3+
## Repository structure
4+
5+
This is a Docusaurus-based documentation site for Moodle developers.
6+
7+
Content is broken into several broad areas:
8+
9+
1. **Documentation for specific versions of Moodle** — guides, best practices, and reference material for Moodle developers. This is the main content of the site and lives in `docs/` and `versioned_docs/`.
10+
2. **General documentation for Moodle developers** — this is the main content of the site and lives in `general/`.
11+
3. **Site configuration and tooling** — this includes Docusaurus config files, build scripts, and other tooling. This lives in the root of the repository and `scripts/`.
12+
4. **Documentation for the Moodle App** - this is a separate section of the site, and lives in:
13+
- `general/app/`
14+
- `general/app.md`
15+
- `general/app_releases/`
16+
- `general/app_releases.md`
17+
18+
5. **Documentation for Moodle for Workplace** - this is a separate section of the site, and lives in:
19+
- `general/workplace/`
20+
21+
## Specific instructions
22+
23+
### Documentation for specific versions of Moodle
24+
25+
The version-specific content lives in two parallel trees:
26+
27+
| Path | Purpose |
28+
|------|---------|
29+
| `docs/` | Current (unreleased/next) version |
30+
| `versioned_docs/version-4.1/` | Moodle 4.1 |
31+
| `versioned_docs/version-4.4/` | Moodle 4.4 |
32+
| `versioned_docs/version-4.5/` | Moodle 4.5 |
33+
| `versioned_docs/version-5.0/` | Moodle 5.0 |
34+
| `versioned_docs/version-5.1/` | Moodle 5.1 |
35+
| `versioned_docs/version-[other-future-version]/` | Moodle [other-future-version] |
36+
37+
The same document can exist in every version. Relative paths are identical across versions — only the version prefix differs. For example:
38+
39+
- `docs/apis/core/hooks/index.md`
40+
- `versioned_docs/version-5.1/apis/core/hooks/index.md`
41+
- `versioned_docs/version-5.0/apis/core/hooks/index.md`
42+
43+
#### Backporting rules
44+
45+
When reviewing or creating a PR that touches `docs/` or `versioned_docs/`:
46+
47+
1. **Check every other version** for the same file path. A fix to a factual error, broken example, or incorrect documentation almost always applies to all versions where that page exists.
48+
49+
2. **Flag missing backports.** If a PR only changes one version but the same issue exists in other versions, the PR is incomplete. Raise this in your review.
50+
51+
3. **Exceptions** — a change does NOT need backporting if:
52+
- It describes a feature that does not exist in that older version (check for a `<Since .../>` inline MD/MDX component in the document body, using either a `version` or `versions` prop, for example `<Since version="X.Y" />` or `<Since versions={["X.Y", "Z.W"]} />`).
53+
- The file does not exist in that version.
54+
- It is a structural/navigation change that is version-specific.
55+
56+
4. **For new PRs you are asked to create**, always update all impacted versions in one PR.
57+
58+
#### PR review checklist (backport completeness)
59+
60+
When reviewing a documentation PR, always check:
61+
62+
- [ ] Does the changed file exist in other versioned directories?
63+
- [ ] Does the same problem exist in those other versions?
64+
- [ ] If yes to both, are those files also updated in this PR?
65+
66+
If any backports are missing, request them before approving.
67+
68+
If possible suggest a patch to add the missing backports, or ask the author to add them.

0 commit comments

Comments
 (0)