Move the docs related with post-commit jobs to new CI infra

general/development/process/release/index.md

@@ -119,7 +119,7 @@ This should happen immediately before the next integration cycle begins on Monda
 | 1. | &#10003; | &#10003; | Check list:<ul><li>Make sure there are no real blockers introduced in the last weekly (install, upgrade...).</li><li>Confirm that the latest [`en_fix` changes](https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc) have been generated and integrated.</li><li>Verify that [all security issues](https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC) have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).</li></ul> | Integration Team |
 | 2. | &#10003; | &#10003; | Verify all unit tests and integration tests have passed (check all current CI servers in use). | Integration Team |
 | 3. | &#10003; |  | Verify QA tests have passed. | Integration Team |
-| 4. | &#10003; | &#10003; | Timing prerequisites (don't continue with the process if not within the time window!):<ol><li>Latest weeklies before the minor/major releases must be done (`moodle-package-extract-and-postprocess` email should confirm this has happened around 09:00 Australia/Perth).</li><li>Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).</li></ol> In practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). **Breaking any of these rules will require manual operation in the server**, forcing repackaging and releasing.<br/><br/>Follow the `mdlrelease` steps:<ul><li>Run the `prerelease.sh` script to generate the target minor (`--type minor`) and major (`--type major`) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg... changes (only for majors)... Triple verify all changes are correct! (can use the `--show` option to inspect them). </li><li>Follow the on-screen instructions.</li><li>Push changes to integration.git (but tags).</li></ul><br/>For major releases, only when a new STABLE branch has been created:<ul><li>Run the `prerelease.sh` script (`--type back-to-dev`) to move `main` to next X.Y+1 development version/branch.</li><li>Push changes to integration.git - note this will lead to the "versions checker" failing for `main`, no problem, it will be fixed by the 1st cloned issue at #12 below).</li><li>Configure `mdlrelease` (`config.sh`) to know about the new `MOODLE_XY` stable branch.</li><li>Update the old CI server(s) by cloning all the `main` jobs to a new `MXY` view (trick: do it down-top, way easier). Don't forget to re-chain the jobs properly.<ul><li>Adjust `main` compare DB jobs to check for upgrade from `MOODLE_XY_STABLE`.</li><li>Configure the "05. Check version.php files" jobs both for the involved branches (`XY_STABLE` and `main`) to define the interval of versions allowed in each.</li><li>Run all them.</li></ul></li><li>Update the new CI infrastructure:<ul><li>`MR1`: Merge pull request for new version in [CI Jobs Repository](https://git.in.moodle.com/integration/nightlyjobs)</li><li>`MR2`: Merge pull request for symlink in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository.</li><li>`MR3`: Merge pull request for skipping the language upgrade in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository.</li><li>Clone all the "B - main" jobs to a new "B - XY" view (there is a [maintenance job](https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/) to perform the operation).</li></ul></li></ul> <br/>Both with minors and majors, continue with the `mdlrelease` steps:<ul><li>Once CI servers have ended and all jobs have passed, **push tags** and run the `release.sh` script to apply the changes to moodle.git.</li><li>If needed configure `mdlrelease` (`config.sh`) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.</li><li>Don't forget the ["After the release"](https://github.com/moodlehq/mdlrelease/#after-the-release) tasks.</li></ul> | Integration Team |
+| 4. | &#10003; | &#10003; | Timing prerequisites (don't continue with the process if not within the time window!):<ol><li>Latest weeklies before the minor/major releases must be done (`moodle-package-extract-and-postprocess` email should confirm this has happened around 09:00 Australia/Perth).</li><li>Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).</li></ol> In practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). **Breaking any of these rules will require manual operation in the server**, forcing repackaging and releasing.<br/><br/>Follow the `mdlrelease` steps:<ul><li>Run the `prerelease.sh` script to generate the target minor (`--type minor`) and major (`--type major`) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg... changes (only for majors)... Triple verify all changes are correct! (can use the `--show` option to inspect them). </li><li>Follow the on-screen instructions.</li><li>Push changes to integration.git (but tags).</li></ul><br/>For major releases, only when a new STABLE branch has been created:<ul><li>Run the `prerelease.sh` script (`--type back-to-dev`) to move `main` to next X.Y+1 development version/branch.</li><li>Push changes to integration.git - note this will lead to the "versions checker" failing for `main`, no problem, it will be fixed by the 1st cloned issue at #12 below).</li><li>Configure `mdlrelease` (`config.sh`) to know about the new `MOODLE_XY` stable branch.</li><li>Update the new CI infrastructure:<ul><li>`MR1`: Merge pull request for new version in [CI Jobs Repository](https://git.in.moodle.com/integration/nightlyjobs)</li><li>`MR2`: Merge pull request for symlink in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository.</li><li>`MR3`: Merge pull request for skipping the language upgrade in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository.</li><li>Clone all the "B - main" jobs to a new "B - XY" view (there is a [maintenance job](https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/) to perform the operation).</li><li>Configure the just cloned "WX0Y.00.00 - Integration post-commit" job to adjust the range of versions allowed and the list of branches to use by the database comparison script.</li></ul></li></ul> <br/>Both with minors and majors, continue with the `mdlrelease` steps:<ul><li>Once CI servers have ended and all jobs have passed, **push tags** and run the `release.sh` script to apply the changes to moodle.git.</li><li>If needed configure `mdlrelease` (`config.sh`) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.</li><li>Don't forget the ["After the release"](https://github.com/moodlehq/mdlrelease/#after-the-release) tasks.</li></ul> | Integration Team |
 | 5. | &#10003; | &#10003; | Post a "git repos updated & tagged" message on the [Partner forum](https://partners.moodle.com/mod/forum/view.php?id=810) | Integration Team |
 | 6. | &#10003; |  | In the [performance comparison repository](https://github.com/moodlehq/moodle-performance-comparison), set the new release commit hash as `$basecommit` in the `main` branch and create a new `MOODLE_XY_STABLE` branch from it. ([example](https://github.com/moodlehq/moodle-performance-comparison/commit/7c875f03e52641f69674235a8947131d77691299)). Also, apply it to the current performance testing infrastructure. | Integration Team |
 | 7. | &#10003; | &#10003; | Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email). | Integration Team |