Add code formatter and CI/CD linter

Start by comparing the dependency, Pint JSON configuration, Composer scripts, and .github/workflows/linter.yml in open-runtimes/executor. Apply the same approach across cache, storage, platform, image, orchestration, and compression. Done means each repository has the requested format and lint commands, matching Pint settings, and a linter workflow running composer lint on pushes.

Introduction

Code formatting is a necessary step of development to keep the code readable and maintainable.
It often comes in a pair with a linter, which is an automated process to ensure formatting has been done properly.

Finishing this issue will give you a basic understanding of PHP, Composer (PHP package manager), and GitHub Actions.

Task summary

Your goal is to implement code formatting in the following repositories:

• utopia-php/cache
• utopia-php/storage
• utopia-php/platform
• utopia-php/image
• utopia-php/orchestration
• utopia-php/compression

1. Install and configure Laravel Pint

Install Pint by using Composer, a PHP dependency manager.

Make sure the version for this dependency is set to automatically upgrade minor and patch versions, but not the major version.
If those terms seem new to you, check out Semantic Versioning.

To configure Pint, you use a specific JSON file. Please refer to the Pint documentation to learn more.
Your goal is to configure Pint in all repositories to the same settings. Please set it to the same settings as we used in another one of our open-source repositories open-runtimes/executor.

2. Add commands to run formatting and linting

Set up Composer scripts called format and lint.

The formatting script should apply proper formatting to files when it runs.
Link script should show linting errors when it runs, but should not do changes to files.

If you ever get stuck, you can again refer to open-runtimes/executor, to see how it's been done there.

3. Add GitHub automation

Add GitHub action to run linter (composer lint) on each push, so pull requests run linter as check.

Store new GitHub action in the linter.yml file.

Just like before, if you feel stuck, you can refer to Open Runtimes Executor to validate your approach.