Merge branch 'refs/heads/master' into 9065_get_contact_by_id

.github/ISSUE_TEMPLATE/z_release_major.md

@@ -18,48 +18,61 @@ assignees: ''
 
 When development is ready to begin one of the engineers should be nominated as a Release Engineer. They will be responsible for making sure the following tasks are completed though not necessarily completing them.
 
-- [ ] Set the version number in the `package.json` and `package-lock.json`, then submit a PR to `master` branch. The easiest way to do this is to use `npm --no-git-tag-version version <major|minor>`.
-- [ ] Ensure that issues from merged commits are closed and mapped to a milestone.
+- [ ] Checkout to a new `<issue>-update-version` branch (eg: `1234-update-version`) and set the version number in the `package.json` and `package-lock.json`. The easiest way to do this is to use `npm --no-git-tag-version version <major|minor>`. Once the version is updated, submit a PR to `master` branch.
+- [ ] Ensure that issues associated with commits merged to `master` since the last release are closed and mapped to the milestone.
 
 # Releasing - Release Engineer
 
-Once all issues have been merged into `master`, and the `master` branch has the new version number, then the release process can start:
+Once the PR has been merged into `master`, and the `master` branch has the new version number, then the release process can start:
 
 - [ ] Create a new release branch from `master` named `<major>.<minor>.x` in `cht-core`. Post a message to #development Slack channel using this template:
 ```
 @core_devs I've just created the `<major>.<minor>.x` release branch. Please be aware that any further changes intended for this release will have to be merged to `master` then backported. Thanks!
 ```
-- [ ] Build a beta named `<major>.<minor>.<patch>-beta.1` by pushing a lightweight git tag (e.g. `git tag <major>.<minor>.<patch>-beta.1`).
+- [ ] Build a beta named `<major>.<minor>.<patch>-beta.1` by creating a lightweight git tag (e.g. `git tag <major>.<minor>.<patch>-beta.1`) and then push the created tag.
 - [ ] Once the CI completes successfully notify the team by writing a message in the #product-team Slack channel:
 ```
 @product_team, I’ve just created the `<major>.<minor>.<patch>-beta.1` tag. 
 Please let me know if there’s any final update we need to make. 
 If all is good, then in 24h, I will start the release. Thanks!
 ```
-- [ ] The beta tag will automatically trigger the scalability build. Once it passes, download the scalability results on S3 at medic-e2e/scalability/$TAG_NAME. Add the release `.json` file to `cht-core/tests/scalability/previous_results`. More info in the  [scalability documentation](https://github.com/medic/cht-core/blob/master/tests/scalability/README.md).
+- [ ] The beta tag will automatically trigger the scalability build. Once it passes, download the scalability results on S3 at medic-e2e/scalability/$TAG_NAME. If you do not have access to the scalability results ask someone in the #product-team who has access. Add the release `.json` file to `cht-core/tests/scalability/previous_results`. More info in the  [scalability documentation](https://github.com/medic/cht-core/blob/master/tests/scalability/README.md).
 - [ ] Add release notes to the [Core Framework Releases](https://docs.communityhealthtoolkit.org/core/releases/) page:
   - [ ] Create a new document for the release in the [releases folder](https://github.com/medic/cht-docs/tree/main/content/en/core/releases).
   - [ ] Ensure all issues are in the GH Milestone, they have human readable descriptions, and that they're correctly labelled. In particular: they have one "Type" label, "UI/UX" if they change the UI, and "Breaking change" if appropriate.
   - [ ] Use [this script](https://github.com/medic/cht-core/blob/master/scripts/release-notes/index.js) to export the issues into our release note format.
   - [ ] Collect known migration steps, descriptions, screenshots, videos, data, and anything else to help communicate particularly important changes. This information should already be on the issue, but if not, prompt the change author to provide it.
   - [ ] Document any required or recommended upgrades to our other products (eg: cht-conf, cht-gateway, cht-android).
   - [ ] Add the release to the [Supported versions](https://docs.communityhealthtoolkit.org/core/releases/#supported-versions) and update the EOL date of the previous release. Update the status of any releases that are past their End Of Life date. Also add a link in the `Release Notes` section to the new release page.
-- [ ] Create a release in GitHub from the release branch so it shows up under the [Releases tab](https://github.com/medic/cht-core/releases) with the naming convention `<major>.<minor>.<patch>`, and change the Target dropdown to the release branch (eg: `4.4.x`). This will create the git tag automatically. Ensure the release notes PR above is merged. Link to the release notes in the description of the release.
-- [ ] Confirm the release build completes successfully and the new release is available on the [market](https://staging.dev.medicmobile.org/_couch/builds_4/_design/builds/_view/releases). Make sure that the document has new entry with `id: medic:medic:<major>.<minor>.<patch>`
-- [ ] Upgrade the [demo](https://demo-cht.dev.medicmobile.org/) instance to this version.
+- [ ] Create a release in GitHub from the release branch so it shows up under the [Releases tab](https://github.com/medic/cht-core/releases) with the naming convention `<major>.<minor>.<patch>`. In the releases tab, you select the "Choose a tag", type tag in the search box, then create a tag for the release `<major>.<minor>.<patch>`. Next, change the Target dropdown to the release branch (eg: `4.4.x`). Ensure the release notes PR above is merged. Add a link to the release notes in the description of the release.
+- [ ] Once you publish the release, confirm the release build completes successfully and the new release is available on the [market](https://staging.dev.medicmobile.org/_couch/builds_4/_design/builds/_view/releases). Make sure that the document has new entry with `id: medic:medic:<major>.<minor>.<patch>`
+- [ ] Upgrade the [demo](https://demo-cht.dev.medicmobile.org/) instance to the newly released version.
 - [ ] Use cht-conf to upload the configuration from the `/config/demo` folder to the `demo-cht.dev` server.
 - [ ] Announce the release on the [CHT forum](https://forum.communityhealthtoolkit.org/c/product/releases/26), under the "Product - Releases" category using this template:
 ```
 *We're excited to announce the release of {{version}} of {{product}}*
 
-New features include {{key_features}}. We've also implemented loads of other improvements and fixed a heap of bugs.
-
-Read the [release notes]({{<paste-url>}}) for full details.
+See below for some highlights, read the [release notes]({{<paste-url>}}) for full details.
 
 Following our support policy, versions {{versions}} are no longer supported. Projects running these versions should start planning to upgrade in the near future. For more details read our [software support documentation](https://docs.communityhealthtoolkit.org/core/releases/#supported-versions).
 
-Check out our [roadmap](https://github.com/orgs/medic/projects/112) to see what we're working on next.
+Check out our [roadmap](https://github.com/orgs/medic/projects/112/views/21) to see what else is currently being working on.
+
+## {{version}} Highlights
+
+### [{{Highlight 1}}]({{<paste-url to section>}})
+
+{{description of highlight section}}
+
+### ### [{{Highlight 2}}]({{<paste-url to section>}})
+
+{{description of highlight section}}
+
+### [And more...]({{paste-url to section}})
+
+We’ve also implemented loads of other improvements and fixed a heap of bugs.
+
 ```
 - [ ] Add one last update to the #product-team Slack channel and use the thread to lead an internal release retrospective covering what went well and areas to improve for next time.
-- [ ] Add any open "known issues" from the prior release that were not fixed in this release. Done by adding the correct `Affects: 4.x.x` label.  
+- [ ] Go to the [Issues tab](https://github.com/medic/cht-core/issues) and filter the issues with `is:issue label:"Affects: 4.x.x" ` , replace `4.x.x` with the previous version number. Add any open "known issues" from the prior release that were not fixed in this release. Done by adding the correct `Affects: 4.x.x` label.  
 - [ ] Mark this issue "done" and close the Milestone.

.github/workflows/build.yml

@@ -23,6 +23,7 @@ jobs:
   build:
     name: Compile the app
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
 
     steps:
     - name: Install bats
@@ -88,6 +89,8 @@ jobs:
     needs: build
     name: ${{ matrix.cmd }}
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
+
     strategy:
       fail-fast: false
       matrix:
@@ -124,6 +127,7 @@ jobs:
     needs: build
     name: ${{ matrix.cmd }}
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
 
     strategy:
       fail-fast: false
@@ -184,6 +188,8 @@ jobs:
     needs: build
     name: ${{ matrix.cmd }}-${{ matrix.suite || '' }}${{ matrix.chrome-version == '90' && '-minimum-browser' || '' }}
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
+
     env:
       CHROME_VERSION: ${{ matrix.chrome-version }}
       JOB_NAME: ${{ matrix.cmd }}-${{ matrix.suite || '' }}${{ matrix.chrome-version == '90' && '-minimum-browser' || '' }}
@@ -343,6 +349,8 @@ jobs:
     needs: [tests, config-tests, test-cht-form]
     name: Publish branch build
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
+
     if: ${{ github.event_name != 'pull_request' }}
 
     steps:
@@ -392,6 +400,8 @@ jobs:
     needs: [publish]
     name: Upgrade from latest release
     runs-on: ubuntu-22.04
+    timeout-minutes: 60
+
     if: ${{ github.event_name != 'pull_request' }}
 
     steps:

.github/workflows/test_couchdb.yml

@@ -1,3 +1,4 @@
+name: Test CouchDB (Conditional)
 on:
   pull_request:
     paths:

.husky/pre-commit

@@ -1,4 +1,5 @@
 #!/usr/bin/env sh
+# shellcheck disable=SC1091 # don't test thirdparty packages
 . "$(dirname -- "$0")/_/husky.sh"
 
 branch="$(git rev-parse --abbrev-ref HEAD)"