Merge branch 'develop' into BUGS-7135-Auth

.circleci/config.yml

@@ -41,7 +41,7 @@ jobs:
   lint:
     working_directory: ~/pantheon-systems/wp-saml-auth
     docker:
-      - image: quay.io/pantheon-public/build-tools-ci:8.x-php8.2
+      - image: quay.io/pantheon-public/build-tools-ci:8.x-php8.0
     steps:
       - checkout
       - restore_cache:
@@ -96,6 +96,7 @@ jobs:
           exit 0
         fi
         terminus auth:login --machine-token=$TERMINUS_TOKEN
+    - run: ./bin/validate-fixture-version.sh
     - run: ./bin/behat-prepare.sh
     - run: ./bin/behat-test.sh --strict
     - run:

.github/workflows/lint-test.yml

@@ -0,0 +1,21 @@
+# On push, run the action-wporg-validator workflow.
+name: Lint and Test
+on: [push]
+jobs:
+  validate-readme-spacing:
+    name: Validate README Spacing
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - uses: pantheon-systems/validate-readme-spacing@v1
+  wporg-validation:
+    name: WP.org Validator
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: WP.org Validator
+        uses: pantheon-systems/action-wporg-validator@1.0.0
+        with:
+          type: plugin

CONTRIBUTING.md

@@ -10,6 +10,8 @@ Pull requests and issues are welcome!
 
 The `develop` branch is the development branch which means it contains the next version to be released. `master` contains the corresponding stable development version. Always work on the `develop` branch and open up PRs against `develop`.
 
+We prefer to squash commits (i.e. avoid merge PRs) from a feature branch into `develop` when merging, and to include the PR # in the commit message. PRs to `develop` should also include any relevent updates to the changelog in readme.txt. For example, if a feature constitutes a minor or major version bump, that version update should be discussed and made as part of approving and merging the feature into `develop`. We do not update the README changelogs for development or process related PRs (i.e. dev-only dependencies, or changes to CI patterns unrelated to new features).
+
 ## Testing
 
 You may notice there are two sets of tests running, on two different services:
@@ -25,12 +27,23 @@ Behat requires a Pantheon site. Once you've created the site, you'll need [insta
 
 ## Release Process
 
-1. Starting from `develop`, cut a release branch named `release_X.Y.Z` containing your changes.
-1. Update plugin version in `package.json`, `README.md`, `readme.txt`, and `wp-saml-auth.php`.
-1. Update the Changelog with the latest changes.
-1. Create a PR against the `master` branch.
-1. After all tests pass and you have received approval from a CODEOWNER (including resolving any merge conflicts), merge the PR into `master`.
-1. [Check the _Build and Tag_ action](https://github.com/pantheon-systems/wp-saml-auth/actions/workflows/build-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets.
-1. Create a [new release](https://github.com/pantheon-systems/wp-saml-auth/releases/new), naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from the `Changelog` section of the `README` into the body of the release and include a link to the closed issues if applicable.
-1. Wait for the [_Release wp-saml-auth plugin to wp.org_ action](https://github.com/pantheon-systems/wp-saml-auth/actions/workflows/wordpress-plugin-deploy.yml) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
-1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/wp-saml-auth/. This may take a few minutes.
+1. From `develop`, checkout a new branch `release_X.Y.Z`.
+1. Make a release commit:
+    * Drop the `-dev` from the version number in `README.md`, `readme.txt`, and `wp-saml-auth.php`.
+    * Commit these changes with the message `Release X.Y.Z`
+    * Push the release branch up.
+1. Open a Pull Request to merge `release_X.Y.Z` into `main`. Your PR should consist of all commits to `develop` since the last release, and one commit to update the version number. The PR name should also be `Release X.Y.Z`.
+1. After all tests pass and you have received approval from a [CODEOWNER](./CODEOWNERS), merge the PR into `master`. "Rebase and merge" is preferred in this case. _Never_ squash to `master`.
+1. Pull `master` locally, create a new tag (based on version number from previous steps), and push up. The tag should _only_ be the version number. It _should not_ be prefixed  `v` (i.e. `X.Y.Z`, not `vX.Y.X`).
+1. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired.
+1. Create a [new release](https://github.com/pantheon-systems/wp-saml-auth/releases/new) using the tag created in the previous steps, naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from the `Changelog` section of [the readme](readme.txt) into the body of the release, including the links to the closed issues if applicable.
+1. Wait for the [_Release wp-saml-auth plugin to wp.org_ action](https://github.com/pantheon-systems/wp-saml-auth/actions/workflows/wordpress-plugin-deploy.yml) to finish deploying to the WordPress.org plugin repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
+1. Check WordPress.org: Ensure that the changes are live on [the plugin repository](https://wordpress.org/plugins/wp-saml-auth/). This may take a few minutes.
+1. Following the release, prepare the next dev version with the following steps:
+    * `git checkout develop`
+    * `git rebase master`
+    * Update the version number in all locations, incrementing the version by one patch version, and add the `-dev` flag (e.g. after releasing `1.2.3`, the new verison will be `1.2.4-dev`)
+    * Add a new `** X.Y.X-dev **` heading to the changelogs
+    * `git add -A .`
+    * `git commit -m "Prepare X.Y.X-dev"`
+    * `git push origin develop`