This GitHub Action allows you to preview WordPress themes in a playground environment. It's designed to be used in pull request workflows to provide a quick and easy way to visualize theme changes.
Name | Description | Required | Default |
---|---|---|---|
github-token |
GitHub token for authentication | Yes | N/A |
base-branch |
The branch to compare against | Yes | main |
ref |
git ref SHA (commit hash) to compare against the base branch | Yes | HEAD |
To use this action in your repo, add the following step:
- For repositories that include multiple themes, assuming that themes are each stored in their own directory at the root of the project:
preview-theme:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}
- name: Preview Theme Changes
uses: vcanales/action-wp-playground-pr-preview@trunk
with:
github-token: <your github token>
base-branch: <your base branch name>
- For repositories that contain a single theme:
preview-theme-changes:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}
- name: Preview Theme Changes
uses: vcanales/action-wp-playground-pr-preview@1fce1282c929f149229dba67c572968746205417
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
ref: ${{ github.event.pull_request.head.sha }}
base-branch: trunk
single-theme: true
Name | Description | Required | Default Value |
---|---|---|---|
github-token |
GitHub token for authentication | Yes | N/A |
ref |
git ref SHA (commit hash) to compare against the base branch | Yes | HEAD |
base-branch |
The branch to compare against | Yes | main |
single-theme |
Whether the repository contains a single theme | No | false |
theme-dir |
The directory where themes are stored | No | . |
wp-version |
The WordPress version to use | No | `` |
php-version |
The PHP version to use | No | `` |
After you've cloned the repository to your local machine or codespace, you'll need to perform some initial setup steps before you can develop your action.
Note
You'll need to have a reasonably modern version of
Node.js handy (20.x or later should work!). If you are
using a version manager like nodenv
or
nvm
, this template has a .node-version
file at the root of the repository that will be used to automatically switch
to the correct version when you cd
into the repository. Additionally, this
.node-version
file is used by GitHub Actions in any actions/setup-node
actions.
-
🛠️ Install the dependencies
npm install
-
🏗️ Package the TypeScript for distribution
npm run bundle
-
✅ Run the tests
$ npm test PASS ./index.test.js ✓ throws invalid number (3ms) ✓ wait 500 ms (504ms) ✓ test runs (95ms) ...
The action.yml
file defines metadata about your action, such as
input(s) and output(s). For details about this file, see
Metadata syntax for GitHub Actions.
When you copy this repository, update action.yml
with the name, description,
inputs, and outputs for your action.
The src/
directory is the heart of your action! This contains the
source code that will be run when your action is invoked. You can replace the
contents of this directory with your own code.
There are a few things to keep in mind when writing your action code:
-
Most GitHub Actions toolkit and CI/CD operations are processed asynchronously. In
main.ts
, you will see that the action is run in anasync
function.import * as core from '@actions/core' //... async function run() { try { //... } catch (error) { core.setFailed(error.message) } }
For more information about the GitHub Actions toolkit, see the documentation.
So, what are you waiting for? Go ahead and start customizing your action!
-
Create a new branch
git checkout -b releases/v1
-
Replace the contents of
src/
with your action code -
Add tests to
__tests__/
for your source code -
Format, test, and build the action
npm run all
This step is important! It will run
ncc
to build the final JavaScript action code with all dependencies included. If you do not run this step, your action will not work correctly when it is used in a workflow. This step also includes the--license
option forncc
, which will create a license file for all of the production node modules used in your project. -
Commit your changes
git add . git commit -m "My first action is ready!"
-
Push them to your repository
git push -u origin releases/v1
-
Create a pull request and get feedback on your action
-
Merge the pull request into the
main
branch
Your action is now published! 🚀
For information about versioning your action, see Versioning in the GitHub Actions toolkit.
You can now validate the action by referencing it in a workflow file. For
example, ci.yml
demonstrates how to reference an
action in the same repository.
steps:
- name: Checkout
id: checkout
uses: actions/checkout@v4
- name: Test Local Action
id: test-action
uses: ./
with:
milliseconds: 1000
- name: Print Output
id: output
run: echo "${{ steps.test-action.outputs.time }}"
For example workflow runs, check out the Actions tab! 🚀
After testing, you can create version tag(s) that developers can use to reference different stable versions of your action. For more information, see Versioning in the GitHub Actions toolkit.
To include the action in a workflow in another repository, you can use the
uses
syntax with the @
symbol to reference a specific branch, tag, or commit
hash.
steps:
- name: Checkout
id: checkout
uses: actions/checkout@v4
- name: Test Local Action
id: test-action
uses: actions/typescript-action@v1 # Commit with the `v1` tag
with:
milliseconds: 1000
- name: Print Output
id: output
run: echo "${{ steps.test-action.outputs.time }}"
This project includes a helper script, script/release
designed to streamline the process of tagging and pushing new releases for
GitHub Actions.
GitHub Actions allows users to select a specific version of the action to use, based on release tags. This script simplifies this process by performing the following steps:
- Retrieving the latest release tag: The script starts by fetching the most recent release tag by looking at the local data available in your repository.
- Prompting for a new release tag: The user is then prompted to enter a new release tag. To assist with this, the script displays the latest release tag and provides a regular expression to validate the format of the new tag.
- Tagging the new release: Once a valid new tag is entered, the script tags the new release.
- Pushing the new tag to the remote: Finally, the script pushes the new tag to the remote repository. From here, you will need to create a new release in GitHub and users can easily reference the new tag in their workflows.