Fix sidebar

docs/DevOps/Operating Procedures/Beta patching procedure.md

@@ -1,64 +1,64 @@
-# 1 - Beta Patching
+# Beta Patching
 
 The contents of this page detail the actions to be undertaken in the event of a desire to provide a patch to a beta release. These procedures may be updated at any point.
 
-# 2 - Related documents
+# 1 - Related documents
 
 The following documents are not considered part of this procedure, but contain additional information which may be beneficial. It is recommended these are read in conjunction with this document.
 
  - [Beta testing procedure](Beta-testing-procedure)
  - [Producing a beta installer guide](Producing-a-beta-installer)
 
-# 3 - Activation of this procedure
+# 2 - Activation of this procedure
 
 Activation of this procedure is done by DevOps at any time that a repository included in the beta installer receives a bug fix to its `main` branch outside of the final sprint of a milestone, or where one or more repositories may have not been included in the initial release where more testing may have been required.
 
 If the development cycle is currently in the final sprint of a milestone, then a beta patch cannot be produced as a new beta is being created, and the bug fix should be dispatched for that beta instead.
 
-# 4 - Procedure for patching - missing repositories
+# 3 - Procedure for patching - missing repositories
 
 Where a repository has not made the initial beta due to issues with testing and the pull request from `develop` into `main` has been closed, this pull request will be reopened and undergo the standard testing and review procedure. Once the Pull Request is merged, DevOps will then carry out the following functions.
 
-# 5 - Procedure for patching - bug fixes
+# 4 - Procedure for patching - bug fixes
 
 A new branch from `main` for the repository to be patched should be made, with code written to resolve the bug and reviewed via a Pull Request in the usual manner without circumventing the standard code review procedures. The Pull Request must be tested thoroughly, ideally against any existing test procedure for that repository where available. Where a test procedure is not available, it is the Discipline Code Lead who is responsible for signing off on the Pull Request. Once the Pull Request is merged, DevOps will then carry out the following functions.
 
-## 5.1 - Patching `develop`
+## 4.1 - Patching `develop`
 
 The same branch (if not deleted) can be used to patch `develop` as well and ensure the bug fix is in both branches so alphas aren't affected either. Thie pull request can be handled in the usual fashion as it will be going into `develop` as part of that milestone and not need any special support. However, it is important that the bug fix is put into `develop` to prevent the patch being needed again at the end of the milestone when `develop` is merged into `main`.
 
-# 6 - Preparing the patch
+# 5 - Preparing the patch
 
 The following actions must be undertaken to prepare the beta patch.
 
-## 6.1 - Change log update
+## 5.1 - Change log update
 
 DevOps responsible for generating an updated change log for the patched beta to include the change being fixed.
 
-## 6.2 - Create the tag on the repository
+## 5.2 - Create the tag on the repository
 
 DevOps is responsible for tagging the repository with the appropriate patch number.
 
 Should the patch number be required, the patch number should always be 1 greater than the most recent patch number. For example, if a beta patch has previously been generated on a different repository (thus making the current beta version Vx.y.b.1) then the beta patch for this repository will become Vx.y.b.2 even if this repository does not have a Vx.y.b.1 patch itself.
 
 An important note to make, is the `TargetCommit` must be set to `main` to target the `main` branch - otherwise it will default to target the default branch (which is `develop` for beta repositories). This will cause issues if not set and other work is committed to `develop` before the tags are completed.
 
-## 6.3 - Produce the beta installers
+## 5.3 - Produce the beta installers
 
 Full details of producing a beta installer can be found in the [Producing a Beta Installer guide](Producing-a-beta-installer).
 
-## 6.4 - Testing the beta installer
+## 5.4 - Testing the beta installer
 
 DevOps is responsible for deciding the scope of testing the patched beta artefact. Where there is any doubt as to the potential scope of changes produced by the patch, a full beta test should be conducted, as per the guidelines in [this procedure](End-of-Milestone-procedure#release-beta-installer-for-testing).
 
 Where the scope of testing can be clearly defined, the Discipline Lead of the affected repository is responsible for reporting back on successful use of the beta patch artefact, using all available test procedures. This work may be delegated down as appropriate to other developers and users, but the Discipline Code Lead takes final responsibility for reporting back.
 
 The testing of the beta patch artefact should be a matter of priority, and the DevOps lead and Discipline Code Lead should remain in regular contact to ensure the results are reported back ASAP. Ideally this should be completed by the end of the next business day at the latest.
 
-## 6.5 - Releasing the beta installer
+## 5.5 - Releasing the beta installer
 
 This is to be done in line with the release of a standard beta, the procedure for which can be found [here](End-of-Milestone-procedure#release-beta-installer-publicly).
 
-# 7 - External website
+# 6 - External website
 
 The BHoM.xyz website should be updated as appropriate, including new API updates were applicable.

docs/DevOps/Operating Procedures/Beta testing procedure.md

@@ -1,28 +1,28 @@
-# 1 - Beta Testing
+# Beta Testing
 
 The contents of this page detail the actions to be undertaken, with approximate timings, at the end of a Milestone to test the Beta installers in the lead up to the release of that Milestones beta. These procedures may be updated at any point. This document forms part of the [End of Milestone Procedure](End-of-Milestone-procedure).
 
-# 2 - Purpose
+# 1 - Purpose
 
 The purpose of this test procedure is to ensure that all aspects of the Beta installers are checked in the lead up to the production of the Beta installer. The outcome of this procedure is to give confidence to those using the Beta that the toolkits and operations will work as designed.
 
-# 3 - Scope
+# 2 - Scope
 
 The scope of testing is restricted to elements of the installer most likely to impact use of the installers. It is not designed to sign off as a complete bug-free installer, however, the state of the Beta should not be worse than that of its previous version. This ensures that each Beta trends towards a more positive setting with each release.
 
-# 4 - Running tests
+# 3 - Running tests
 
 Each discipline lead is responsible for ensuring suitable, adequate, and reasonable tests are conducted on each of the toolkits within their group. These tests should be run as often as possible during a milestone, but are strictly monitored during the final sprint of a milestone.
 
 During the final sprint, a discipline lead must ensure they, or a suitable member of their team, carries out an adequate test of each toolkit using a given Beta installer. Building from source is not permitted for these tests, as the purpose is to ensure the final Beta installer is fit for purpose.
 
 It is advised that testing utilises the formal test procedures where applicable to make the process of testing and verifying the code base easier, as test procedures should capture the core functionality. Where a test procedure does not exist, it is the responsibility of the discipline lead to ensure suitable testing is carried out.
 
-## 4.1 - Test Reports
+## 3.1 - Test Reports
 
 Each day during the final sprint, the DevOps Lead or their appointed deputy is responsible for collating the test reports. Test reports should confirm what toolkits have been tested, whether any toolkits have been exempted (see below), and any issues that have been found. It is the responsibility of each Discipline Lead to provide accurate information upon request on the state of their testing.
 
-## 4.2 - Fixing issues
+## 3.2 - Fixing issues
 
 It is the responsibility of each Discipline Lead to triage issues found as a result of testing. Any bug which did not exist in the previous Beta should be prioritised, following standard best practice for issue management generally. Bugs which existed in the previous Beta should not be prioritised during this period (though may be triaged and resolved if there are no other issues).
 
@@ -40,7 +40,7 @@ Discipline leads are responsible for ensuring they have adequate resource to res
 
 If an issue is resolved with the approval of DevOps, and merged to the repository's `develop` branch, DevOps will reproduce the Pull Request which merges `develop` into `main` to include this additional fix.
 
-## 4.3 - Exceptions
+## 3.3 - Exceptions
 
 It may be appropriate for a toolkit to not receive testing every day during the final sprint, providing the following criteria can be met.
 
@@ -50,10 +50,10 @@ It may be appropriate for a toolkit to not receive testing every day during the
 
 The Discipline Lead of the toolkits concerned may consult with other relevant stakeholders, including other Discipline Leads, however, the final responsibility for testing, or skipping, a toolkit resides with the Discipline Lead. It is recommended that should any of the criteria above not be met, that the toolkit undergo a subsequent retest.
 
-# 5 - Merging `develop` into `main`
+# 4 - Merging `develop` into `main`
 
 Once suitable testing has been conducted on the Pull Request which is aimed to be deployed in the Beta, the testers must comment with suitable approving reviews. The Discipline Code Lead must then inform DevOps that the Pull Request is ready to be merged, and DevOps will then merge the Pull Request for deployment if it is deemed appropriate to do so. Instances where it may not be appropriate to merge a Pull Request include if the Pull Request is depending on code in a higher repository (for example BHoM_Engine) that has not yet been merged. In these cases the Pull Request may have to wait, and may risk not being included if the higher repository Pull Request is not subsequently deployed.
 
-# 6 - Final Beta test
+# 5 - Final Beta test
 
 After the creation of the Beta artefact, the Beta must be signed off by each Discipline Lead. The Beta must be tested against all available Test Procedures for code residing within the installer. Additional tests are allowed, but cannot be used as substitutions to the test procedures. Where a test procedure does not exist, the Discipline Lead is responsible for ensuring adequate and suitable testing is performed for that area of code.