Run prettier or php-cs-fixer with GitHub Actions

The public release of GitHub Actions is coming closer and closer. Over the past few weeks I've added a handful of workflows to my projects.

One workflow is really like, is to run prettier and php-cs-fixer to automatically format my code and commit the fixed files back to the repository.

Run prettier#

First, install prettier in your project.

yarn add prettier --dev

(I like to be in control of what version of software is run; that's why I always install these dependencies directly in a project and don't rely on globally installed versions)

Next, add the following workflow file. I've stored mine under .github/workflows/format_prettier.yml.

name: Format (prettier)

on:
    push:
        branches:
            - 'master'
    pull_request:
        paths:
            - '**.css'
            - '**.js'
            - '**.vue'

jobs:
    prettier:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
              with:
                  ref: ${{ github.head_ref }}

            - name: Install
              run: yarn install
              env:
                  CI: true

            - name: Run prettier
              run: yarn run prettier --write 'src/**/*.{css,js,vue}'

            - uses: stefanzweifel/git-auto-commit-action@v4
              with:
                  commit_message: Apply prettier changes

The Workflow is quite easy to understand:

1. It only runs when a commit is pushed to master or when the pull_request-event is fired and when .css, .js or .vue files have been changed.
2. Next, the Workflow checks out our project and installs all of our NPM-dependencies
3. It will then run prettier and search for files within the src-directory (update the path for your projects).
4. In the end, my own git-auto-commit Action will be executed. It will detect that files have been changed, create a new commit and push the changes back to the GitHub repository.

Run php-cs-fixer#

The process off running php-cs-fixer is very similar. First we have to install php-cs-fixer in our project:

composer require friendsofphp/php-cs-fixer --dev

In addition, you have to set up a .php_cs-config file. Checkout the documentation on how to do that.

Finally, we can add another workflow to our project. I've stored mine under .github/workflows/format_php.yml.

name: Format (PHP)

on:
    push:
        branches:
            - 'master'
    pull_request:
        paths:
            - '**.php'

jobs:
    php-cs-fixer:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
              with:
                  ref: ${{ github.head_ref }}

            - name: Install
              run: composer install

            - name: Run php-cs-fixer
              run: ./vendor/bin/php-cs-fixer fix

            - uses: stefanzweifel/git-auto-commit-action@v4
              with:
                  commit_message: Apply php-cs-fixer changes

As you can see, this workflow is very similar to the previous one. The only changes are the paths of changed files we're looking for and the command which executes php-cs-fixer.

If you don't want to install php-cs-fixer in your project or don't want to do the time intensive composer install on GitHub Actions, you can use the php-cs-fixer Action by Oskar Stark.

name: Format (PHP)

on:
    pull_request:
        paths:
            - '**.php'

jobs:
    php-cs-fixer:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
              with:
                  ref: ${{ github.head_ref }}

            - name: Run php-cs-fixer
              uses: docker://oskarstark/php-cs-fixer-ga

            - uses: stefanzweifel/git-auto-commit-action@v4
              with:
                  commit_message: Apply php-cs-fixer changes

Both workflows will replace the need for services like StyleCI in my projects. The only remaining question is, if these workflows will also work, when a contributor makes a Pull Request in one of my projects.

I also like the decision of GitHub to switch from the HCL syntax to YAML for Actions. It makes reading and developing those workflows a lot easier.