|
| 1 | +# The name of the Github Action that displays in github.com/<username>/<repo>/actions |
| 2 | +name: Deploy to WordPress.org Repository |
| 3 | + |
| 4 | +# Here we can define the events "on" which the action should be triggered. |
| 5 | +on: |
| 6 | + |
| 7 | + # Since we want to publish new versions of our plugin, we only want this action to |
| 8 | + # run when publishing a new release. |
| 9 | + # |
| 10 | + # The released version of the plugin will then be deployed to the repository. |
| 11 | + # |
| 12 | + # This allows us to run and manage plugin releases from a single location. |
| 13 | + release: |
| 14 | + |
| 15 | + # run only when a new release is published, but not when it's classified as a pre-release. |
| 16 | + types: [released] |
| 17 | + |
| 18 | +# A list of jobs involved in this workflow. |
| 19 | +jobs: |
| 20 | + |
| 21 | + # A unique job identifier. |
| 22 | + # |
| 23 | + # Github Actions can have multiple jobs and each can be referenced by its name. |
| 24 | + # However, we only need to run a few steps here and they can be handled in a single job. |
| 25 | + deploy_to_wp_repository: |
| 26 | + |
| 27 | + # The proper name for the job being run. |
| 28 | + name: Deploy to WP.org |
| 29 | + |
| 30 | + # The environment this job should run on. In the context of WordPress, ubuntu-latest is |
| 31 | + # pretty typical. Since we are only interacting with git and subversion, Ubuntu is perfect |
| 32 | + # for this. |
| 33 | + # |
| 34 | + # Github does offer other platforms if you need them: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on |
| 35 | + runs-on: ubuntu-latest |
| 36 | + |
| 37 | + # Every job has a specific set of steps that it goes through to do its "work". |
| 38 | + # |
| 39 | + # Each step has a two key elements: |
| 40 | + # • Name |
| 41 | + # • a "run" command (an arbitrary CLI command to execute) OR a "uses" command that pulls in and executes a 3rd party action. |
| 42 | + steps: |
| 43 | + |
| 44 | + # Most workflows begin by checking out the repository into the workflow filesystem. |
| 45 | + # |
| 46 | + # This is just like cloning a repository except it only checks out the specific commit |
| 47 | + # the job is executed for. In our case here, the commit that the release is attached to. |
| 48 | + - name: Checkout code |
| 49 | + uses: actions/checkout@v2 |
| 50 | + |
| 51 | + # Optional: If your plugin is using composer dependencies, we want to include them |
| 52 | + # WITHOUT the dev dependencies. |
| 53 | + - name: Build |
| 54 | + run: | |
| 55 | + npm install |
| 56 | + npm run build |
| 57 | + - name: WordPress Plugin Deploy |
| 58 | + |
| 59 | + # You can add unique ids to specific steps if you want to reference their output later in the workflow. |
| 60 | + # |
| 61 | + # Here, this unique identifier lets us use the output from the action to get the zip-path later. |
| 62 | + id: deploy |
| 63 | + |
| 64 | + # The use statement lets us pull in the work done by 10up to deploy the plugin to the WordPress repository. |
| 65 | + uses: 10up/action-wordpress-plugin-deploy@stable |
| 66 | + |
| 67 | + # Steps can also provide arguments, so this configures 10up's action to also generate a zip file. |
| 68 | + with: |
| 69 | + generate-zip: true |
| 70 | + |
| 71 | + # Steps can also set environment variables which can be configured in the Github settings for the |
| 72 | + # repository. Here, we are using action secrets SVN_USERNAME, SVN_PASSWORD, and PLUGIN_SLUG which |
| 73 | + # authenticate with WordPress and lets the action deploy our plugin to the repository. |
| 74 | + # |
| 75 | + # To learn more about setting and using secrets with Github Actions, check out: https://docs.github.com/en/actions/security-guides/encrypted-secrets?tool=webui#about-encrypted-secrets |
| 76 | + env: |
| 77 | + SVN_USERNAME: ${{ secrets.SVN_USERNAME }} |
| 78 | + SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }} |
| 79 | + |
| 80 | + # After the deploy, we also want to create a zip and upload it to the release on Github. We don't want |
| 81 | + # users to have to go to the repository to find our plugin :). |
| 82 | + - name: Upload release asset |
| 83 | + uses: actions/upload-release-asset@v1 |
| 84 | + env: |
| 85 | + # Note, this is an exception to action secrets: GH_TOKEN is always available and provides access to |
| 86 | + # the current repository this action runs in. |
| 87 | + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
| 88 | + |
| 89 | + with: |
| 90 | + # Get the URL for uploading assets to the current release. |
| 91 | + upload_url: ${{ github.event.release.upload_url }} |
| 92 | + |
| 93 | + # Provide the path to the file generated in the previous step using the output. |
| 94 | + asset_path: ${{ steps.deploy.outputs.zip-path }} |
| 95 | + |
| 96 | + # Provide what the file should be named when attached to the release (plugin-name.zip) |
| 97 | + asset_name: ${{ github.event.repository.name }}.zip |
| 98 | + |
| 99 | + # Provide the file type. |
| 100 | + asset_content_type: application/zip |
0 commit comments