Add CI/CD: automated tests on PRs and deploy to WordPress.org on tag

[mostafasoufi]

🚨 Problem

The repository has no automated testing and no automated release process today:

• ❌ No tests. There is no tests/ directory and no PHPUnit setup. Date conversion, leap-year logic and number conversion are the heart of this plugin, and a regression there (for example around Nowruz or the last day of Esfand) is only noticed after users report it. Recent issues like خطای Fatal در صفحه پرداخت ووکامرس؛ متد convertNonPersianValuesInCheckout مقدار null برمی‌گرداند #331 (fatal in WooCommerce checkout) show that a broken release reaches every site at once.
• ❌ No CI. Pull requests (for example Fix early translation loading during plugin version checks #332) cannot be verified automatically. Reviewers have to pull the branch and test by hand, and nothing checks that the code still runs on PHP 7.4 (the declared minimum) as well as PHP 8.4.
• ❌ Manual releases. Publishing to WordPress.org means checking out SVN, copying files, and committing by hand. It is easy to ship development files (node_modules, package-lock.json, webpack.config.js, .idea, ...) or to forget to update the tag, and only the person with SVN access can release.

✅ Proposal

Add the same CI/CD setup that wp-sms uses:

1. 🧪 Testing workflow (.github/workflows/testing.yml) – runs PHPUnit on top of the official WordPress test library for every pull request and every push to master, on PHP 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4, plus a php -l syntax check.
2. 🚀 Deploy workflow (.github/workflows/deploy.yml) – when a version tag (for example 6.4) is pushed, 10up/action-wordpress-plugin-deploy builds the plugin and commits it to the WordPress.org SVN repository. A .distignore file keeps development files out of the release ZIP.
3. 📁 Test scaffolding – phpunit.xml.dist, tests/bootstrap.php, bin/install-wp-tests.sh and a first set of tests for Gregorian ↔ Jalali conversion, leap years, Persian digit helpers, plugin constants and SVG sanitizing.

🎁 Benefits

• 🛡️ Every PR is tested on 6 PHP versions before anyone reviews it; a red check tells the author what broke.
• 📅 Calendar edge cases (Nowruz, Esfand 29/30, leap years) are locked in by tests so they cannot silently regress.
• ⚡ Releasing becomes git tag 6.4 && git push --tags. No SVN client, no manual copying, no accidental development files in the ZIP.
• 👥 Any maintainer with push access can release; the SVN credentials live in repository secrets, not on someone's laptop.
• 📈 The scaffolding is in place, so new tests can be added next to any future bug fix.

🔍 How it works in wp-sms (demo)

• Testing workflow: https://github.com/veronalabs/wp-sms/blob/master/.github/workflows/testing.yml
• Deploy workflow: https://github.com/veronalabs/wp-sms/blob/master/.github/workflows/deploy.yml
• Example runs: https://github.com/veronalabs/wp-sms/actions

🔧 What the maintainers need to do

Add two repository secrets (Settings → Secrets and variables → Actions):

• SVN_USERNAME – the WordPress.org account that owns the wp-parsidate plugin
• SVN_PASSWORD – its password

Without them the testing workflow still runs; only the deploy step is skipped/fails.

I have a pull request ready for this.