How to reuse GitHub Actions Workflows

30/07/2023 /

Original link: https://qq52o.me/2819.html

github-actions.png

WordPress is going to release version 6.3 recently. Before the release, I will receive an email of WordPress xx is imminent! Are your plugins ready? to remind me to update the compatible plugins.

The following plugins did not update readme.txt in time to indicate compatibility with the new version, mainly because they felt that updating one by one was time-consuming and laborious.

A few days ago, I found an action ( 10up/action-wordpress-plugin-deploy ) that supports pushing directly to WordPress Plugin SVN on GitHub.

So I wrote a deploy.yml workflow:

 name: Deploy to WordPress.org on: pull_request: release: types: [ published ] jobs: tag: name: New release runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Setup PHP uses: shivammathur/setup-php@v2 with: php-version: '7.0' tools: composer - name: Build run: | composer install -o --no-dev working-directory: cos-sdk-v5 - name: Set Version if: github.event_name == 'pull_request' run: | echo "VERSION=ci" >> $GITHUB_ENV - name: WordPress Plugin Deploy id: deploy uses: 10up/action-wordpress-plugin-deploy@stable with: dry-run: $ generate-zip: $ env: SVN_PASSWORD: $ SVN_USERNAME: $ SLUG: sync-qcloud-cos - name: Upload release asset uses: actions/upload-release-asset@v1 if: github.event_name == 'release' env: GITHUB_TOKEN: $ with: upload_url: $ asset_path: $ asset_name: $.zip asset_content_type: application/zip

Well, yes, it works. But later I found out that the problem is not so simple. Now there are 10+ plugins. If you copy and submit one by one, it is no problem now, but if you want to modify the content in yml later, you have to modify them one by one again, which is still a repetitive task.

At this point, the content of this article is introduced: how to reuse Workflows?

Why do you need to reuse?

Workflows can be made reusable, rather than being copied and pasted from one workflow to another. A reusable workflow can be called from another workflow by itself and by anyone who has access to it.

Reuse workflows to avoid duplication. This makes the workflow easier to maintain.

Organizations can also build reusable workflow libraries that can be centrally maintained.

Create reusable workflows

To make a workflow reusable, the value of on must include workflow_call :

 on: workflow_call:

It is also possible to define inputs and secrets that can be passed from the calling workflow and then used in the called workflow.

 on: workflow_call: inputs: build: default: false type: boolean php: default: "7.0" type: string working-directory: default: sdk type: string

If secrets are inherited using secrets: inherit in the calling workflow, then secrets can be referenced even if they are not explicitly defined in the on key.

Everything else is consistent with the normal workflow definition.

File after modification

 name: WordPress Plugin Deploy on: workflow_call: inputs: build: default: false type: boolean php: default: "7.0" type: string working-directory: default: sdk type: string jobs: deploy: name: Deploy to WordPress.org runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Setup PHP if: $ uses: shivammathur/setup-php@v2 with: php-version: $ tools: composer - name: Install dependencies if: $ run: composer install -o --no-dev working-directory: $ - name: Set Version if: github.event_name == 'pull_request' run: | echo "VERSION=ci" >> $GITHUB_ENV - name: WordPress Plugin Deploy id: deploy uses: 10up/action-wordpress-plugin-deploy@stable with: dry-run: $ generate-zip: $ env: SVN_PASSWORD: $ SVN_USERNAME: $ SLUG: $ - name: Upload release asset uses: actions/upload-release-asset@v1 if: github.event_name == 'release' env: GITHUB_TOKEN: $ with: upload_url: $ asset_path: $ asset_name: $.zip asset_content_type: application/zip

transfer

Reusable workflows can be invoked through uses syntax.

Reusable workflows can be invoked directly in jobs , not from steps .

Reusable workflow files can be referenced using one of the following syntaxes:

  • {owner}/{repo}/.github/workflows/{filename}@{ref} for reusable workflows in public and private repositories.
  • ./.github/workflows/{filename} for reusable workflows within the same repository.

In the first option, {ref} can be SHA , a release tag, or a branch name.

 name: Deploy to WordPress.org on: pull_request: release: types: [ published ] jobs: deploy: uses: sy-records/.github/.github/workflows/wordpress-plugin-deploy.yaml@main with: build: true secrets: inherit

This completes the reusable workflow definition.

The caller in the example of this article: https://github.com/sy-records/upyun-uss-wordpress/blob/master/.github/workflows/deploy.yml

The callee in the example of this article: https://github.com/sy-records/.github/blob/main/.github/workflows/wordpress-plugin-deploy.yaml

The complete content can be viewed in the GitHub documentation: Reusing workflows

This article is transferred from: https://qq52o.me/2819.html
This site is only for collection, and the copyright belongs to the original author.