Automate Larastan with GitHub Actions!

2023.11.06

• Web system development

6

920

Hello!

My name is Matsuki from the System Development Department.

In this article, I would like to explain how to set up Larastan automatically using GitHub Actions.

What are GitHub Actions?

is GitHub's official feature that automates predefined processes

GitHub Actions automatically executes the processes defined in a dedicated file as a condition for executing the Actions, such as creating a push or pull request to a repository.

How to use GitHub Actions

To use GitHub Actions, you can use it by creating a .yml file under the "/.github/workflows" directory.

There are two ways to create this directory: you can create it from GitHub, or you can directly create the directory and files yourself.

This time, I created it myself, so I will not explain how to create it on GitHub.

What is Larastan?

Larastan refers to a static analysis tool specialized for Laravel.

Originally, PHP had a static analysis tool called PHPStan, which could be used to find problems in the PHP code without running it.

It checks the types of variables and functions (int type, string type, etc.) and confirms the safety of the program.

Outputs detailed error messages for errors found in the code. This allows you to identify where the problem is occurring.

Larastan is an extension of PHPStan designed for Laravel.

The content is basically the same as PHPStan, but you can understand the features, dependencies, and types specific to Laravel projects, and improve the quality of your source code.

environment

PHP: 8.2
Laravel: 10.x

Points to note

GitHub Actions are written in a yaml (yml) file.

The description is done in a tree structure, so

Be sure to be aware of which hierarchy the part you are describing falls into when writing.

For example, if the key "jobs" in the first line of the code below is in the same hierarchy as "phpstan" in the second line, it will not work properly.

By writing "phpstan" one level deeper than "jobs", it will work properly.

jobs: phpstan: // This is the same level, so it cannot be moved. jobs: phpstan: // Since it is one layer deep, it has a tree structure and can run normally.

code to use

The code we will use this time is as follows.

The code below is written in "/.github/workflows/larastan.yml".

name: Larastan on: push: jobs: phpstan: runs-on: ubuntu-latest steps: - uses: actions/ [email protected] with: fetch-depth: 0 - name: Setup PHP uses: shivammathur/setup-php@v2 with: php-version: 8.2 tools: composer, cs2pr coverage: none - name: Composer install run: composer install working-directory: ./src - name: Larastan install run: composer require nunomaduro/larastan --dev - name: Run PHPStan run: vendor/bin/phpstan analyze -c ./phpstan.neon working-directory: ./src

Based on the above code, I will explain in detail how GitHub Actions and Larastan work automatically.

name:

This field describes the name of the workflow to be registered in GitHub Actions.

By entering this, it will be displayed on the GitHub Actions screen.

Here we have registered the name "Larastan".

If not registered, the relative path of the file will be registered.

In this case, it will be registered with the name "./.github/workflows/larastan.yml".

on:

You can decide which actions trigger the workflow.

This is called a "trigger".

In the code used this time, "Push to GitHub" is the trigger to run Larastan.

In addition to the push timing, you can also set triggers in detail, such as triggering when a pull request is created, or only when a specified branch is pushed.

jobs:

This is an item where you write the processes that will be executed within the workflow.

For example, to run Larastan, you will need to install php, install composer, install Larastan, and run the command.

This item describes such operations.

phpstan:

Job creation and job name.

If you use the name key in a job, you can set the name that will be displayed in the GitHub UI, but if you do not set it, it will be replaced with the name of the job.

runs-on:

Define the virtual machine type.

When setting up a virtual machine,

you can choose from three options: GitHub hosted runner
, runner larger than GitHub hosted runner
, and self-hosted runner

This time we will use the first GitHub hosted runner (hereinafter referred to as runner).

There are several types of runners, and you can choose from three: Linux, Windows, and macOS.

Basically, I think there is no problem with using Linux, but please choose according to your environment.

This time I am using the latest Ubuntu as a virtual machine.

steps:

Write the command to be executed.

The commands listed here are executed in order from the top, so if you do them in the wrong order, it will cause an error, so be careful when writing them.

uses:

Specify the action to perform.

The action used here is a module called "actions/checkout".

The role is used to use code from the repository.

Also, when checking out, only the code of the first commit of the specified branch is retrieved, so fetch-depth: 0 as additional information in the with: , the entire history of all branches is retrieved. Masu.

name:

Here name: is the name of the step as it appears in GitHub Actions.

"shivamathur/setup-php" is a php setup module used with GitHub Actions.

with:

By writing, you can write supplementary information.
The php used this time is version 8.2.

tools:

It refers to the tools provided in "shivamathur/setup-php".
Specify the library management tool composer to be used as the tool.

coverage:

Here you can specify coverage.

Coverage refers to the coverage rate of the code.

There are two tools that can be used: "Xdebug" and "PCOV".

I will omit the detailed explanation here, but I will briefly explain,

Xdebug is a PHP debugging tool that also allows you to get coverage.

PCOV is a dedicated tool for PHP coverage analysis.

Also, if you do not specify anything, you can disable it by specifying "none".

For example, if you want to obtain coverage from Xdebug, you can do so by specifying the following.

coverage: xdebug

This time, since I am running larastan, coverage is not necessary, so I disabled it.

run:

Write the command to be executed in the terminal etc.

You can specify the installation destination using working-directory, and it is installed in the src directory under the project root.

I am running this because larastan is not installed in setup-php yet, so I am directly installing the larastan library.

The last step is to run larastan.

vendor/bin/phpstan analyze is the usual larastan execution command, but -c ./phpstan.neon specifies the larastan execution configuration to refer to phpstan.neon under the current directory.

You can set the level etc. with phpstan.neon, and the contents of phpstan.neon used this time are as follows.

includes: - ./vendor/nunomaduro/larastan/extension.neon parameters: paths: - src level: 1

Based on the above items, it will be possible to automatically run Larastan.

summary

What did you think?

This time, I have omitted the parts that are not related to the code, so

If you are interested, please see the GitHub Actions documentation.

thank you very much.

lastly

We have opened the service site "SEKARAKU Lab" for the system development department to which I belong.
Beyond is a one-stop service for everything from server design and construction to operation, so if you have any trouble with server-side development, please feel free to contact us.

● SEKARAKU Lab: https://sekarakulab.beyondjapan.com

If you found this article helpful , please give it a like!

6

Loading...

6

920