Porquê desenvolvedores, cada um de nós tem uma maneira específica de formatar nosso código e podemos ter Sua visita nos ajuda a continuar oferecendo o melhor para você! extremamente fortes sobre nossas preferências. Isso é bom se formos o único desenvolvedor trabalhando em um projeto, mas pode ser um problema real quando você está trabalhando com uma equipe de desenvolvedores. Nessa situação, é guardado que cada membro da equipe terá visões muito diferentes sobre uma vez que o código deve ser formatado. Ao escolher um único estilo de codificação e segui-lo, podemos evitar todos os tipos de raiva e maçada.
Depois de escolher um padrão, você deve impor o padrão de codificação usando uma utensílio uma vez que PHP_CodeSniffer que deve ser configurado para ser executado involuntariamente quando enviamos nosso código para nosso repositório de código-fonte. A desvantagem disso é que geralmente significa que somente recebemos um relatório nos dizendo quais são os problemas e logo temos que tirar um tempo do nosso dia ocupado para consertar nosso código. Mas e se pudéssemos ter o GitHub Actions resolvendo involuntariamente o supremo de problemas provável para nós?
Neste item, criaremos um processo para fazer exatamente isso.
Configurando Nosso Projeto
Para nosso exemplo de hoje, criaremos um projeto hospedado no GitHub que tem uma feição de ação do GitHub para validar involuntariamente nosso código em relação ao PSR-12 padrão de codificação. Usaremos PHP_CodeSniffer para fazer isso.
Se você não teve a chance de usar o PHP_CodeSniffer, é uma livraria que nos fornece duas ferramentas de risca de comando para executar validação e embelezamento do nosso código. A primeira que vamos discutir é o PHP Code Sniffer (phpcs) utensílio que nos permite validar nosso código em relação a um padrão de codificação e nos mostra uma vez que podemos “consertar” nosso código para atender ao padrão.
Para debutar, vou gerar um novo diretório e usar o composer para instalar o PHP_CodeSniffer.
% mkdir phpcbf-automatically && cd phpcbf-automatically
% composer require --dev squizlabs/PHP_CodeSniffer
Using version ^3.10 for squizlabs/php_codesniffer
./composer.json has been created
Running composer update squizlabs/php_codesniffer
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
- Locking squizlabs/php_codesniffer (3.10.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Downloading squizlabs/php_codesniffer (3.10.1)
- Installing squizlabs/php_codesniffer (3.10.1): Extracting archive
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!
Logo, vou gerar um registo formatado de uma forma que viola o padrão de codificação PSR12.
function hello()
{
echo "hi";
}
Agora quando eu corro phpcs neste registo e especificar o padrão de codificação PSR12 veremos alguns erros:
“`
$ ./vendor/bin/phpcs –standard=psr12 ruim.php
ARQUIVO: /Usuários/scottkeck-warren/tmp/phpcbf-automatically/bad.php
ENCONTRADOS 5 ERROS AFETANDO 5 LINHAS
1 | ERRO | [x] Os blocos de cabeçalho devem ser separados por uma única risca em branco
2 | ERRO | [x] Esperado 1 espaço em seguida a palavra-chave FUNCTION; 0 encontrado
3 | ERRO | [x] A chave de início deve estar na mesma risca da enunciação
4 | ERRO | [x] Risco recuada incorretamente; esperava-se pelo menos 4 espaços, encontrados 0
5 | ERRO | [x] Esperado 1 novidade risca no final do registo; 0 encontrado
PHPCBF PODE CORRIGIR AS 5 VIOLAÇÕES DE SNIFF MARCADAS AUTOMATICAMENTE
Tempo: 141ms; Memória: 6MB
“`
O “[x]” especifica que podemos emendar as violações involuntariamente, mas queremos ver esses erros no GitHub, logo não vamos corrigi-los agora.
Agora podemos configurar nosso diretório para ser um repositório git, aditar nossos arquivos e enviá-los para um repositório GitHub que já criei.
$ git init
Reinitialized existing Git repository in /Users/scottkeck-warren/tmp/phpcbf-automatically/.git/
$ echo "vendor" >> .gitignore
$ git add bad.php composer.json composer.lock .gitignore
$ git commit -a -m "Initial Commit"
[main (root-commit) b839ccc] Initial Commit
3 files changed, 109 insertions(+)
create mode 100644 bad.php
create mode 100644 composer.json
create mode 100644 composer.lock
$ git remote add origin [email protected]:ScottKeckWarren/phpcbf-automatically.git
$ git push -u origin main
Agora precisamos configurar uma ação do GitHub para executar involuntariamente phpcs quando enviamos código para nosso repositório.
Para fazer isso, vamos gerar um registo chamado “.github/workflows/phpcs.yml” e preenchê-lo com o seguinte.
name: PHPCS
on: [push]
jobs:
phpcs:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: 8.3
- name: Install Composer dependencies
run: composer install --no-progress --prefer-dist --optimize-autoloader
- name: Run PHPCS
run: ./vendor/bin/phpcs --standard=psr12 ./bad.php
Levante é um registo YAML muito vital do GitHub Actions. Não vou passar por todos os passos, mas se você estiver curioso sobre cada passo, pode aprender mais em nosso item “Automating Our Tests With GitHub Actions”.
Agora vamos fazer commit deste registo e enviá-lo para o GitHub.
git add .; git commit -a -m "Added PHPCS.yml"; git push
Se olharmos para a aba “Ações” do nosso projeto, veremos que nossa ação foi executada, mas falhou porque nosso registo falhou uma vez que esperávamos.
Corrigindo Nosso Código
PHP_CodeSniffer vem com uma segunda utensílio de risca de comando chamada PHP Code Beautifier and Fixer (phpcbf). Podemos decorrer phpcbf para emendar qualquer erro que encontramos usando phpcs que têm o “[X]”neles, o que tende a ser muito grande.
Podemos executá-lo localmente executando ./vendor/bin/phpcbf --standard=psr12 bad.php e logo comprometer os resultados e nossos phpcs a verificação passará. Mas não quero ter que executar isso manualmente. Quero continuar a “automatizar todas as coisas”, logo, em vez disso, usarei as ações do GitHub para executar involuntariamente phpcbf e enviar os resultados diretamente para nosso repositório.
Para fazer isso, criaremos um novo YAML chamado “.github/workflows/phpcbf.yml”.
name: Automatically Run PHPCBF
on: [push]
jobs:
Sua visita nos ajuda a continuar oferecendo o melhor para você! />runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: 8.3
- name: Install Composer dependencies
run: composer install --no-progress --prefer-dist --optimize-autoloader
- name: Run PHPCBF
run: ./vendor/bin/phpcbf --standard=psr12 ./bad.php
continue-on-error: true
- name: Commit Changes
uses: stefanzweifel/git-auto-commit-action@v4
É extremamente semelhante ao “phpcs.yml” que criamos anteriormente, com algumas diferenças importantes.
A primeira é que temos uma seção que define as permissões para permitir que as ações executadas no registo sejam gravadas em nosso repositório.
permissions:
contents: write
O próximo é que temos a lanço que é executada phpcbf e logo especificamos que as Ações do GitHub devem sempre continuar. Isso ocorre porque se phpcbf corrige qualquer coisa, ele retornará um código de erro e a ação será interrompida. Não queremos isso porque queremos que a ação continue para que possamos confirmar os resultados.
- name: Run PHPCBF
run: ./vendor/bin/phpcbf --standard=psr12 ./
continue-on-error:true
Por término, usaremos a ação git-auto-commit-action para gerar um novo commit.
- name: Commit Changes
uses: stefanzweifel/git-auto-commit-action@v4
Adicionaremos leste registo ao nosso repositório e confirmaremos os resultados.
git add .github/workflows/phpcbf.yml
git commit -m "Added `phpcbf` action"
git push
Agora podemos voltar para nossa aba de ações e ver que duas ações estão em realização agora.
Depois a desfecho da nossa ação “Executar PHPCBF involuntariamente”, podemos olhar o histórico de confirmações do nosso código e ver que ele foi revisto involuntariamente.
Agora o raso é que nosso phpcs a verificação que também foi executada falhará porque será executada usando o commit inicial e não o commit recém-criado.
O GitHub Actions também não reexecuta involuntariamente nossas Actions depois que o commit automático é criado. Acho que isso é para evitar um loop infinito, mas é irritante. Quando isso acontece, precisamos retrair as alterações, gerar um novo commit e logo enviar de volta para o GitHub para que possamos obter.
Só correndo algumas vezes
Minha equipe tem uma regra de que todas as alterações que vão para o branch principal precisam passar por um pull request para que a mudança possa ser validada. Logo não queremos que nenhum código seja diferente no branch principal involuntariamente.
Para emendar isso, podemos especificar que a ação seja executada somente em uma solicitação de pull e não em cada push.
name: Automatically Run PHPCBF
on: [pull_request]
Temos outras ações que queremos executar somente quando alguns arquivos mudam. Por exemplo, usamos GitHub Actions para compilar o CSS e o JS para nosso aplicativo, mas isso só precisa suceder quando fazemos Sua visita nos ajuda a continuar oferecendo o melhor para você! em diretórios específicos.
Podemos usar a opção path para especificar somente isso.
on:
pull_request:
paths:
- resources/js/**
- resources/css/**
Novamente as ações do GitHub são superpoderosas
O que você precisa saber
- Sua equipe precisa de um padrão de codificação
- Use PHP_CodeSniffer para impor o padrão
- Use o GitHub Actions para impor o padrão involuntariamente
Tags:
Crédito: Natividade Original
