top of page

Posts

Automate Larastan with GitHub Actions!



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

What is “GitHub Actions”?

GitHub Actions is an official feature of GitHub that automates predefined processes. GitHub Actions automatically executes a process that you define in a dedicated file, such as creating a push or pull request to a repository, as a condition for executing the Actions.

How to use GitHub Actions?

To use GitHub Actions, you need to create a .yml file under the directory named '/.github/workflows'.

There are two ways to create this directory: you can either create it from GitHub or create the directory and file manually.

Since I have manually created it already, I will omit the explanation of how to create it on GitHub.

What is Larastan?

Larastan refers to a static analysis tool specific to Laravel.


Originally, PHP had a static analysis tool called PHPStan, which was designed to find problems in PHP code without executing it. It checks the types of variables and functions (int, string, etc.) to make sure that the program is safe.


It outputs detailed error messages for any error it finds in the code, making it possible to pinpoint where the problem is occurring.


Larastan is an extension of PHPStan designed specifically for Laravel.


While its functionality is similar to PHPStan, it understands Laravel-specific features, dependencies, and types, thus improving the quality of the source code.

Environment

PHP: 8.2

Laravel: 10.x

Note

The GitHub Actions are described in a yaml (yml) file. 

Since the description is done in a tree structure, make sure that the sections you are describing are at the appropriate level in the hierarchy. 

For example, if the key 'phpstan' appears at the same level as the key 'jobs' in the code below, it will not function correctly. Placing 'phpstan' one level deeper than 'jobs' will allow it to function properly.


Code

The code I’m using this time is as follows:

And it is written in '/.github/workflows/larastan.yml'.



Based on the provided code, I will explain the mechanism by which GitHub Actions and Larastan are set up to run automatically.

Name:

This is the field where you specify the name of the workflow that will be registered in GitHub Actions.

By providing a name here, it will be displayed in the GitHub Actions dashboard.

In this instance, I have registered the name as "Larastan."

However, if you don't specify a name, the workflow will be registered with the relative path of the file. In this case, it would be registered as "./.github/workflows/larastan.yml".

On:

You can determine which action triggers the execution of the workflow. 

This is called a "trigger". 

In the code we are using this time, I have set "Push to GitHub '' as 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 section is dedicated to writing the processes to be executed within the workflow.

For example, to run Larastan, you need to install PHP, Composer, Larastan, and then execute the command.

This section is where you document such operations.

phpstan:

The creation of a job and the job name.

You can use the "name" key in a job to set the name that will be displayed in the GitHub UI. However, if no configuration is provided, it will be replaced with the job's name.

runs-on:

This defines the type of virtual machine.

To configure the virtual machine, you can choose from the following three options:

  • GitHub-hosted Runner

  • Runner Larger Than GitHub-hosted Runner

  • Self-hosted Runner

This time I will use the first option, GitHub-hosted Runner (referred to as "runner").

Within the runner, there are several types available, and you can choose from Linux, Windows, and macOS.

Generally, I think there is no problem with using Linux, but please select according to your specific environment.

For this instance, I am using the latest version of Ubuntu as the virtual machine.

steps:

Here, it describes the command to be executed.

Since the commands here will be executed sequentially from top to bottom, be careful when writing them as errors can occur if they are described in the wrong order.


uses:

It specifies the action to be executed.

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

Its role is to be used to retrieve the code from the repository.

In addition, since only the code from the head commit of the specified branch is retrieved at checkout, fetch-depth: 0 is specified as supplementary information in the with: field so that the entire history of all branches is retrieved.

name:

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

"shivammathur/setup-php" is the php setup module used in GitHub Actions.

with:

By including additional information in the description, you can specify that PHP version 8.2 will be used.

tools:

It refers to the tools provided in "shivammathur/setup-php".

Here it specifies the library management tool composer is to be used.

coverage:

Coverage can be specified here.

Coverage refers to the percentage of code coverage, and there are two tools that can be used: "Xdebug" and "PCOV".

While I'll skip detailed explanations, to summarize:

Xdebug is a debugging tool for PHP that also provides coverage.

PCOV is a dedicated PHP coverage analysis tool.

It can also be disabled by specifying "none" if nothing is specified.

For example, if you want to get coverage from Xdebug, you can do so by specifying as follows. 



This time, for the execution of larastan, coverage is disabled as it is not necessary.

run:

It describes commands to be executed at a terminal or other location.


The installation directory can be specified by 'working-directory', and the installation is performed in the 'src' directory under the project root.


The reason we are running this command is that larastan is not yet installed in 'setup-php', so we are installing the larastan library directly.


The last step is to run larastan.


Up to vendor/bin/phpstan analyze are the usual larastan execution commands, but the -c . /phpstan.neon specifies that the configuration for running larastan should refer to phpstan.neon under the current directory.


Settings such as 'level' can be configured in the 'phpstan.neon' file, of which the content being used this time is as follows.


Based on the above, Larastan can be executed automatically.

Summary

How was it?

Since I omitted the parts unrelated to the code this time, if you are interested, please refer to the GitHub Actions documentation.

Thank you very much.

This blog post is translated from a blog post written by Matsuki on our Japanese website Beyond Co..


bottom of page