Merge pull request #1587 from ScilifelabDataCentre/HMS-2171-create-re…

…lease-template

Release template

.github/pull_request_template.md

@@ -10,77 +10,78 @@ If there is a field which you are unsure about, enter the edit mode of this desc
 
 ## 1. Description / Summary
 
-_Add a summary of the changes in this PR and the related issue._
+**Add a summary here**: What does this PR add/change and why?
 
 ## 2. Jira task / GitHub issue
 
-_Link to the github issue or add the Jira task ID here._
+**Is this a GitHub issue?** --> Add the link to the github issue
 
-## 3. Type of change
+**Is this from a Jira task?** --> If your branch does not contain info regarding the Jira task ID, put it here.
 
-What _type of change(s)_ does the PR contain?
+## 3. Type of change - Add label
 
-**Check the relevant boxes below. For an explanation of the different sections, enter edit mode of this PR description template.**
+**What _type of change(s)_ does the PR contain? For an explanation of the different options below, enter edit mode of this PR description template.**
 
-- [ ] New feature
-  - [ ] Breaking: _Why / How? Add info here._ <!-- Should be checked if the changes in this PR will cause existing functionality to not work as expected. E.g. with the master branch of the `dds_cli` -->
-  - [ ] Non-breaking <!-- Should be checked if the changes will not cause existing functionality to fail. "Non-breaking" is just an addition of a new feature. -->
-- [ ] Database change: _Remember the to include a new migration version, **or** explain here why it's not needed._ <!-- Should be checked when you've changed something in `models.py`. For a guide on how to add the a new migration version, look at the "Database changes" section in the README.md. -->
-- [ ] Bug fix <!-- Should be checked when a bug is fixed in existing functionality. If the bug fix also is a breaking change (see above), add info about that beside this check box. -->
-- [ ] Security Alert fix <!-- Should be checked if the PR attempts to solve a security vulnerability, e.g. reported by the "Security" tab in the repo. -->
-  - [ ] Package update <!-- Should be checked if the Security alert fix consists of updating a package / dependency version -->
-    - [ ] Major version update <!-- Should be checked if the package / dependency version update is a major upgrade, e.g. 1.0.0 to 2.0.0 -->
-- [ ] Documentation <!-- Should be checked if the PR adds or updates documentation such as e.g. Technical Overview or a architecture decision (dds_web/doc/architecture/decisions.) -->
-- [ ] Workflow <!-- Should be checked if the PR includes a change in e.g. the github actions files (dds_web/.github/*) or another type of workflow change. Anything that alters our or the codes workflow. -->
-- [ ] Tests **only** <!-- Should only be checked if the PR only contains tests, none of the other types of changes listed above. -->
+_If you do not want this change to be included in release notes, add the label `skip-changelog`._
+
+- New feature
+  - Breaking --> label: `breaking` <!-- If the changes in this PR will cause existing functionality to not work as expected. E.g. with the master branch of the `dds_cli`. Add info here on how the change is breaking. -->
+  - Non-breaking --> label: `feature` <!-- If the changes will not cause existing functionality to fail. "Non-breaking" is just an addition of a new feature. -->
+- Database change --> label: `feature` or none at all.
+  _Remember the to include a new migration version, **or** explain here why it's not needed._ <!-- If you've changed something in `models.py`. For a guide on how to add the a new migration version, look at the "Database changes" section in the README.md. -->
+- Bug fix --> label: `bug` <!-- If a bug is fixed in existing functionality. If the bug fix also is a breaking change (see above), add info about that beside this check box. -->
+- Security Alert fix <!-- If the PR attempts to solve a security vulnerability, e.g. reported by the "Security" tab in the repo. -->
+  - Package update --> label: `dependency` <!-- If the Security alert fix consists of updating a package / dependency version -->
+    - Major version update <!-- If the package / dependency version update is a major upgrade, e.g. 1.0.0 to 2.0.0 -->
+- Documentation --> label can be skipped, will be included in "other changes" <!-- If the PR adds or updates documentation such as e.g. Technical Overview or a architecture decision (dds_web/doc/architecture/decisions.) -->
+- Workflow --> label: `skip-changelog` <!-- If the PR includes a change in e.g. the github actions files (dds_web/.github/*) or another type of workflow change. Anything that alters our or the codes workflow. -->
+- Tests **only** --> label: `skip-changelog` <!-- If the PR only contains tests, none of the other types of changes listed above. -->
 
 ## 4. Additional information
 
-- [ ] [Sprintlog](../SPRINTLOG.md) <!-- Add a row at the bottom of the SPRINTLOG.md file (not needed if PR contains only tests). Follow the format of previous rows. If the PR is the first in a new sprint, add a new sprint header row (follow the format of previous sprints). -->
-- [ ] Blocking PRs <!-- Should be checked if there are blocking PRs or other tasks that need to be merged prior to this. Add link to PR or Jira card if this is the case. -->
-  - [ ] Merged <!-- Should be checked if the "Blocking PRs" box was checked AND all blocking PRs have been merged / fixed. -->
-- [ ] PR to `master` branch: \_If checked, read [the release instructions](../doc/procedures/new_release.md) <!-- Check this if the PR is made to the `master` branch. Only the `dev` branch should be doing this. -->
+- [ ] I have added an entry to the [Sprintlog](../SPRINTLOG.md) <!-- Add a row at the bottom of the SPRINTLOG.md file (not needed if PR contains only tests). Follow the format of previous rows. If the PR is the first in a new sprint, add a new sprint header row (follow the format of previous sprints). -->
+- [ ] This is a PR to the `master` branch: _If checked, read [the release instructions](../doc/procedures/new_release.md)_ <!-- Check this if the PR is made to the `master` branch. Only the `dev` branch should be doing this. -->
   - [ ] I have followed steps 1-8. <!-- Should be checked if the "PR to `master` branch" box is checked AND the specified steps in the release instructions have been followed. -->
 
 ## 5. Actions / Scans
 
-_Check the boxes when the specified checks have passed._
-
-**For information on what the different checks do and how to fix it if they're failing, enter edit mode of this description or go to the [PR template](../.github/pull_request_template.md).**
+**Make sure that the following checks/actions have passed.**
 
-- [ ] **Black**
+- **Black**
 <!--
   What: Python code formatter.
   How to fix: Run `black .` locally to execute formatting.
 -->
-- [ ] **Prettier**
+- **Prettier**
 <!--
   What: General code formatter. Our use case: MD and yaml mainly.
   How to fix: Run npx prettier --write . locally to execute formatting.
 -->
-- [ ] **Yamllint**
+- **Yamllint**
 <!--
   What: Linting of yaml files.
   How to fix: Manually fix any errors locally.
 -->
-- [ ] **Tests**
+- **Tests**
 <!--
   What: Pytest to verify that functionality works as expected.
   How to fix: Manually fix any errors locally. Follow the instructions in the "Run tests" section of the README.md to run the tests locally.
   Additional info: The PR should ALWAYS include new tests or fixed tests when there are code changes. When pytest action has finished, it will post a codecov report; Look at this report and verify the files you have changed are listed. "90% <100.00%> (+0.8%)" means "Tests cover 90% of the changed file, <100 % of this PR's code changes are tested>, and (the code changes and added tests increased the overall test coverage with 0.8%)
 -->
-- [ ] **CodeQL**
+- **CodeQL**
 <!--
   What: Scan for security vulnerabilities, bugs, errors.
   How to fix: Go through the alerts and either manually fix, dismiss or ignore. Add info on ignored or dismissed alerts.
 -->
-- [ ] **Trivy**
+- **Trivy**
 <!--
   What: Security scanner.
   How to fix: Go through the alerts and either manually fix, dismiss or ignore. Add info on ignored or dismissed alerts.
 -->
-- [ ] **Snyk**
+- **Snyk**
 <!--
   What: Security scanner.
   How to fix: Go through the alerts and either manually fix, dismiss or ignore. Add info on ignored or dismissed alerts.
 -->
+
+If an action does not pass and you need help with how to solve it, enter edit mode of this PR template or go to the [PR template](../.github/pull_request_template.md).

.github/release.yml

@@ -0,0 +1,23 @@
+# file location/name: .github/release.yml
+changelog:
+  exclude:
+    labels: # A list of labels that exclude a pull request from appearing in release notes.
+      - skip-changelog
+    authors: # A list of user or bot login handles whose pull requests are to be excluded from release notes.
+      - dependabot[bot]
+  categories:
+    - title: 🚀 Features
+      labels:
+        - feature
+    - title: 🐛 Bug Fixes
+      labels:
+        - bug
+    - title: ⛓️‍💥 Breaking Changes
+      labels:
+        - breaking
+    - title: 🛡️ Dependencies
+      labels:
+        - dependency
+    - title: Other Changes
+      labels:
+        - "*" # Catch-all for pull requests that didn't match any of the previous categories

SPRINTLOG.md

@@ -473,3 +473,7 @@ _Nothing merged during this sprint_
 
 - New version: 2.9.0 ([#1584](https://github.com/ScilifelabDataCentre/dds_web/pull/1584))
 - Instructions regarding database migrations moved to migrations directory, and Linkspector action added to scan for incorrect links in MD ([#1576](https://github.com/ScilifelabDataCentre/dds_web/pull/1576))
+
+# 2024-12-20 - 2025-01-10
+
+- Make release template ([1587](https://github.com/ScilifelabDataCentre/dds_web/pull/1587))

doc/procedures/new_release.md

@@ -10,7 +10,7 @@
 3.  Fork a new branch from `dev` (locally)
 4.  Update the version [changelog](../../CHANGELOG.rst), located at `dds_web/CHANGELOG.rst`
 
-    **Tip:** Use the PR to `master` to see all changes since last release.
+    **Tip:** Create a [release **draft**](https://github.com/ScilifelabDataCentre/dds_web/releases/new) with `Target: dev`, click `Generate release notes` and copy paste the release notes into the Changelog. **DO NOT PUBLISH THE RELEASE**
 
     - The new version should be at the top of the page
     - List the changes that the users will / may notice
@@ -56,46 +56,4 @@
 
        An image of the web / api will be published to the [GitHub Container Registry](https://codefresh.io/csdp-docs/docs/integrations/container-registries/github-cr/)
 
-10. Perform redeployment
-
-    The method for this _depends on the situation_ / size of and reason for the upgrade.
-
-    - **Bug**, affecting the DDS functionality - Fix ASAP
-
-      1.  Add a new _Message of the Day_ (MOTD) informing the users of an ongoing / immediate update - (see CLI)
-      2.  Send the MOTD via email (see CLI)
-      3.  Send a message in the `dds-status` slack channel to inform the units
-      4.  Ask for a redeployment
-
-          1.  Go to the [sysadmin repository](https://github.com/ScilifelabDataCentre/sysadmin/issues)
-          2.  Create a new issue and fill in the following information
-
-              `Title`
-
-                  DDS: Redeploy the production instance (`dds`)
-
-              `Leave a comment`
-
-                  Please redeploy the production instance of the DDS.
-                  Image: <Name of the latest release / tag, e.g. v1.1.0 >
-
-                  Fill in the [manual log](https://scilifelab.atlassian.net/wiki/spaces/deliveryportal/pages/2318565390/Production) on Confluence.
-
-    - **New feature** or bug that does not need an immediate fix
-
-      Cluster maintenance is performed the first Wednesday (that is a work day) of every month. The DDS is redeployed during this as well. However, we still need to inform the users of the upcoming upgrade, and the sysadmins of which image they should deploy.
-
-      1.  Go to the [sysadmin repository](https://github.com/ScilifelabDataCentre/sysadmin/issues)
-      2.  Create a new issue and fill in the following information
-
-          `Title`
-
-              DDS: Schedule redeployment of production instance (`dds`) for next cluster maintenance window
-
-          `Leave a comment`
-
-              During the next cluster maintenance (`<Weekday, Day / Month, Time>`), please redeploy the production instance of the DDS.
-
-              Image: <Name of the latest release / tag, e.g. v1.1.0 >
-
-              Fill in the [manual log](https://scilifelab.atlassian.net/wiki/spaces/deliveryportal/pages/2318565390/Production) on Confluence.
+10. Perform redeployment during maintenance window.