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 install 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:
    pull_request:
        paths:
            - '**.css'
            - '**.js'
            - '**.vue'

jobs:
    prettier:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v1

            - 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@v2.1.0
              with:
                  commit_message: Apply prettier changes
                  branch: ${{ github.head_ref }}
              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The Workflow is quite easy to understand:

  1. It only runs 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:
    pull_request:
        paths:
            - '**.php'

jobs:
    php-cs-fixer:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v1

            - name: Install
              run: composer install

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

            - uses: stefanzweifel/git-auto-commit-action@v2.1.0
              with:
                  commit_message: Apply php-cs-fixer changes
                  branch: ${{ github.head_ref }}
              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

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@v1

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

            - uses: stefanzweifel/git-auto-commit-action@v2.1.0
              with:
                  commit_message: Apply php-cs-fixer changes
                  branch: ${{ github.head_ref }}
              env:
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

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.