Skip to content

Latest commit

 

History

History
49 lines (35 loc) · 4.6 KB

CONTRIBUTING.md

File metadata and controls

49 lines (35 loc) · 4.6 KB

Contributing

The best way to contribute to the development of this plugin is by participating on the GitHub project:

https://github.com/pantheon-systems/wp-saml-auth

Pull requests and issues are welcome!

Workflow

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:

  • Travis CI runs the PHPUnit test suite, which mocks interactions with SimpleSAMLphp.
  • Circle CI runs the Behat test suite against a Pantheon site, to ensure the plugin's compatibility with the Pantheon platform. This includes configuring a fully-functional instance of SimpleSAMLphp.

Both of these test suites can be run locally, with a varying amount of setup.

PHPUnit requires the WordPress PHPUnit test suite, and access to a database with name wordpress_test. If you haven't already configured the test suite locally, you can run bash bin/install-wp-tests.sh wordpress_test root '' localhost.

Behat requires a Pantheon site. Once you've created the site, you'll need install Terminus, and set the TERMINUS_TOKEN, TERMINUS_SITE, and TERMINUS_ENV environment variables. Then, you can run ./bin/behat-prepare.sh to prepare the site for the test suite.

Release Process

  1. From develop, checkout a new branch release_X.Y.Z.
  2. 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.
  3. 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.
  4. After all tests pass and you have received approval from a CODEOWNER, merge the PR into master. "Rebase and merge" is preferred in this case. Never squash to master.
  5. 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).
  6. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired. Specifically, ensure that the vendor/ directory exists, since that's where the SAML libraries are sourced from.
  7. Create a new release 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 into the body of the release, including the links to the closed issues if applicable.
  8. Wait for the Release wp-saml-auth plugin to wp.org action 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.
  9. Check WordPress.org: Ensure that the changes are live on the plugin repository. This may take a few minutes.
  10. 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