Merge branch 'develop' into develop

.github/release-pull-request-template.md

@@ -10,6 +10,7 @@
 - [ ] Update this pull request's status from `draft` to `ready to merge`.
 - [ ] Review: Do a review of the commit to the `stable` branch to ensure the contents of the diffs are as expected.
 - [ ] Test: Check out the `stable` branch and test it locally to ensure everything works as expected.  It is recommended that you rename the existing `distributor` directory and check out `stable` fresh because switching branches does not delete files.  This can be done with `git clone --single-branch --branch stable [email protected]:10up/distributor.git`
+- [ ] Either perform a regression testing utilizing the available [Critical Flows](https://10up.github.io/Open-Source-Best-Practices/testing/#critical-flows) and Test Cases or if [end-to-end tests](https://10up.github.io/Open-Source-Best-Practices/testing/#e2e-testing) cover a significant portion of those Critical Flows then run e2e tests.  Only proceed if everything tests successfully.
 - [ ] Release: Create a [new release](https://github.com/10up/distributor/releases/new), naming the tag and the release with the new version number, and **targeting the `stable` branch**.  Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the [closed issues on the milestone](https://github.com/10up/distributor/milestone/#?closed=1).  The release should now appear under [releases](https://github.com/10up/distributor/releases).
 - [ ] Check release: Wait for the [Publish Release Action](https://github.com/10up/distributor/actions?query=workflow%3A%22Publish+Release%22) to complete, and then check the latest release to ensure that the ZIP has been attached as an asset.  Download the ZIP and inspect the contents to be sure they match the contents of the `stable` branch.
 - [ ] Close milestone: Edit the [milestone](https://github.com/10up/distributor/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.

.github/workflows/cypress.yml

@@ -108,7 +108,7 @@ jobs:
           npx mochawesome-report-generator tests/cypress/reports/mochawesome.json -o tests/cypress/reports/
           cat ./tests/cypress/reports/mochawesome.md >> $GITHUB_STEP_SUMMARY
     - name: Make artifacts available
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       if: failure()
       with:
         name: cypress-artifact

.github/workflows/generate-zip.yml

@@ -42,7 +42,7 @@ jobs:
           rm -rf ./release && unzip ${{ github.event.repository.name }}.zip -d ./release
 
       - name: Upload the ZIP file as an artifact
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4
         with:
           name: ${{ github.event.repository.name }}
           path: release

CONTRIBUTING.md

@@ -22,6 +22,10 @@ Pull requests represent a proposed solution to a specified problem. They should
 
 For more on how 10up writes and manages code, check out our [10up Engineering Best Practices](https://10up.github.io/Engineering-Best-Practices/).
 
+### Testing
+
+Helping to test an open source project and provide feedback on success or failure of those tests is also a helpful contribution.  You can find details on the Critical Flows and Test Cases in [this project's GitHub Wiki](https://github.com/10up/distributor/wiki/Critical-Flows) as well as details on our overall approach to [Critical Flows and Test Cases in our Open Source Best Practices](https://10up.github.io/Open-Source-Best-Practices/testing/#critial-flows).  Submitting the results of testing via our Critical Flows as a comment on a Pull Request of a specific feature or as an Issue when testing the entire project is the best approach for providing testing results.
+
 ## Workflow
 
 The `develop` branch is the development branch which means it contains the next version to be released. `stable` contains the current latest release and `trunk` contains the corresponding stable development version. Always work on the `develop` branch and open up PRs against `develop`.