Automate Larastan with GitHub Actions!
table of contents
Hello!
My name 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 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 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 which actions trigger the workflow.
This is called a "trigger".
The code we will use this time is triggered by "pushing to GitHub" and executes 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 need to install php, composer, and Larastan
This item 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:
Define the virtual machine type.
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
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 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:
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, 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
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
6
Loading...6 
The person who wrote this article
About the author
