Automate Larastan with GitHub Actions!
table of contents
Hello!
This is Matsuki from the System Development Department
In this article, I would like to explain how to set up Larastan to run automatically using GitHub Actions
What are GitHub Actions?
is an official GitHub feature that automates predefined processes
GitHub Actions automatically executes processes defined in a dedicated file when you push to a repository or create a pull request as a condition for executing the Action
How to use GitHub Actions
To use GitHub Actions, you can create a .yml file under the directory "/.github/workflows"
There are two ways to create this directory: you can create it from GitHub, or you can create the directory and files yourself and use them
Since I created it myself this time, I will not go into how to create it on GitHub
What is Larastan?
Larastan is a static analysis tool specifically designed for Laravel
Originally, PHP had a static analysis tool called PHPStan, which could find problems in PHP code without executing it
It checks the types of variables and functions (int type, string type, etc.) to ensure the safety of the program
If it finds an error in your code, it will output a detailed error message, allowing you to pinpoint where the problem is
Larastan is an extension of PHPStan designed for Laravel
The content is basically the same as PHPStan, but it allows you to understand the functions, 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 described in a yaml (yml) file
The description is done in a tree structure, so
When writing, be aware of which level the part you are writing corresponds to
For example, if the "jobs" key on the first line of the code below is at the same level as the "phpstan" key on the second line, it will not work properly
By entering "phpstan" one level deeper than "jobs", it will work properly
jobs: phpstan: // This is the same hierarchy, so it cannot be run. jobs: phpstan: // Because it is one level deeper, it becomes a tree structure and can be 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 code above, we will explain in detail how GitHub Actions and Larastan work automatically
name:
This field specifies 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 are registering 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 what action will trigger the workflow to run
This is called a "trigger."
The code we will use this time is triggered by "pushing to GitHub" and executes Larastan
You can not only set the timing of the push, but also set detailed triggers, such as triggering when a pull request is created, or only when a specified branch is pushed
jobs:
This is the section where you write the processes that will be executed within the workflow
For example, to run Larastan, you need to install php, composer, and Larastan
This section describes such operations
phpstan:
Job creation and job name
You can use the name key in the job to set the name that will be displayed in the GitHub UI, but if you don't set it, it will be replaced by the job name
runs-on:
Defines the type of virtual machine
There are three options for configuring a virtual machine
: a GitHub hosted runner
, a runner larger than the GitHub hosted runner,
or a self-hosted runner
For this example, we will use the first GitHub hosted runner (hereinafter referred to as the runner)
There are several types of runners, and you can choose from three: Linux, Windows, and macOS
Basically, there should be no problem with using Linux, but please choose according to your environment
This time we are using the latest Ubuntu as a virtual machine
steps:
Enter the command to be executed
The commands listed here are executed in order from top to bottom, so if you get the order wrong it will cause an error, so please write them carefully
uses:
Specifies the action to perform
The action used here is a module called "actions/checkout"
As a role, it is used to use the code in the repository
Also, since only the code of the first commit of the specified branch is retrieved when checking out, fetch-depth: 0 as additional information in the with: , the entire history of all branches is retrieved.
name:
Where name: is the name of the step that will be displayed in GitHub Actions
"shivammathur/setup-php" is a php setup module used with GitHub Actions
with:
You can write additional information by writing this.
The php used in this example is version 8.2.
tools:
This refers to the tool provided in "shivammathur/setup-php".
Specify the library management tool composer as the tool to use.
coverage:
Here you can specify the coverage
Coverage refers to the code coverage rate
There are two tools you can use: "Xdebug" and "PCOV"
I won't go into detail here, but to put it simply,
Xdebug is a PHP debugging tool that also provides coverage
PCOV is a tool specifically designed for PHP coverage analysis
If you do not want to specify anything, you can disable it by specifying "none"
For example, if you want to get coverage from Xdebug, you can do so by specifying it as follows:
coverage: xdebug
This time we are running larastan, so coverage is not necessary and has been disabled
run:
Enter the command to be executed in the terminal
The installation destination can be specified using working-directory, and it will be installed in the src directory under the project root
The reason for running this is that larastan has not yet been installed in setup-php, so the larastan library is installed directly
Finally, it's time to run larastan
vendor/bin/phpstan analyze , the larastan execution command is the usual, but -c ./phpstan.neon specifies that the configuration to run larastan should refer to phpstan.neon in the current directory.
You can set levels and other settings using 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
Taking the above into consideration, you will be able to run Larastan automatically
summary
What did you think?
This time, I have omitted the parts that are not related to the code, so
Interested in learning more? Check out the GitHub Actions documentation
thank you very much
lastly
The System Development Department, to which I belong, has launched a service site called "SEKARAKU Lab."
Beyond offers a one-stop service for everything from server design and construction to operation, so if you have any problems with server-side development, please feel free to contact us.
● SEKARAKU Lab: https://sekarakulab.beyondjapan.com
6
Loading...6 
The person who wrote this article
About the author
