From 877f89153313dcbe461e9d391ead39ae41367121 Mon Sep 17 00:00:00 2001 From: Dharmesh Patel Date: Fri, 2 Dec 2022 16:42:42 +0530 Subject: [PATCH 1/3] Added "Build release zip" GitHub Action and Updated release instructions. --- .github/workflows/build-release-zip.yml | 33 +++++++++++++++++++++++++ CONTRIBUTING.md | 1 + 2 files changed, 34 insertions(+) create mode 100644 .github/workflows/build-release-zip.yml diff --git a/.github/workflows/build-release-zip.yml b/.github/workflows/build-release-zip.yml new file mode 100644 index 00000000..f7881809 --- /dev/null +++ b/.github/workflows/build-release-zip.yml @@ -0,0 +1,33 @@ +name: Build release zip + +on: + workflow_dispatch: + push: + branches: + - trunk + +jobs: + build: + name: Build release zip + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v3 + + - name: Cache vendor + id: cache-composer + uses: actions/cache@v3 + env: + cache-name: cache-vendor + with: + path: | + vendor + ~/.composer/cache + key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/composer.json') }} + + - name: Install Composer dependencies + if: steps.cache-vendor.outputs.cache-hit != 'true' + run: composer install --no-dev + + - name: Generate ZIP file + uses: 10up/action-wordpress-plugin-build-zip@stable diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 225d0e2f..4f7b81b8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,6 +37,7 @@ The `develop` branch is the development branch which means it contains the next 1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk` (`git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version. 1. Test: While still on the `trunk` branch, test for functionality locally. 1. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`). +1. Test the pre-release ZIP locally by downloading it from the **Build release zip** action artifact to ensure the plugin doesn't break after release. 1. Release: Create a [new release](https://github.com/10up/safe-svg/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` 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/safe-svg/milestone/#?closed=1). 1. SVN: Wait for the [GitHub Action](https://github.com/10up/safe-svg/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/safe-svg/. This may take a few minutes. From 30c3dd5f8c65af2f9da584a2c2b2b714e4236237 Mon Sep 17 00:00:00 2001 From: Dharmesh Patel Date: Fri, 9 Dec 2022 17:24:05 +0530 Subject: [PATCH 2/3] Remove duplicate test step. --- CONTRIBUTING.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4f7b81b8..fbd16d08 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -35,7 +35,6 @@ The `develop` branch is the development branch which means it contains the next 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`. 1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. 1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk` (`git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version. -1. Test: While still on the `trunk` branch, test for functionality locally. 1. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`). 1. Test the pre-release ZIP locally by downloading it from the **Build release zip** action artifact to ensure the plugin doesn't break after release. 1. Release: Create a [new release](https://github.com/10up/safe-svg/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` 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/safe-svg/milestone/#?closed=1). From 18c7bcd767563c46aa6998b96ca4d0a4e6c78252 Mon Sep 17 00:00:00 2001 From: Dharmesh Patel Date: Fri, 9 Dec 2022 17:32:35 +0530 Subject: [PATCH 3/3] Update release instructions. --- CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fbd16d08..cbdaf433 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,8 +34,9 @@ The `develop` branch is the development branch which means it contains the next 1. Props: update `CREDITS.md` with any new contributors, confirm maintainers are accurate. 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`. 1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. -1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk` (`git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version. +1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk`, ensuring you pull the most recent changes into `develop` first (`git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version. 1. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`). +1. [Compare develop and trunk](https://github.com/10up/safe-svg/compare/trunk...develop) to ensure no additional changes were missed. 1. Test the pre-release ZIP locally by downloading it from the **Build release zip** action artifact to ensure the plugin doesn't break after release. 1. Release: Create a [new release](https://github.com/10up/safe-svg/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` 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/safe-svg/milestone/#?closed=1). 1. SVN: Wait for the [GitHub Action](https://github.com/10up/safe-svg/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.