What do you Review in Code? If you do code-review, what do you mostly do?
- Look for patterns, explain them, report them everywhere or just somewhere and hope the other person will fix them all.
- Discuss the design and why and what should be done about it.
Well, the 2nd cannot be automated, unless you’re able to put it in clear step-by-step, e.g SOLID laws in procedural code. So you still have to do that, sorry.
Dead Fat Code
But 1st step can be easily automated. How? Well, let’s take a dead code for example. In the last project I’ve helped to improve with Rector, there were 2 years of dead-code piled up. A dead that you have to:
- debug if broken
- review if changed anything related to it
So many human-hours wasted. In the end, we removed over 12 % of “dead fat code”. Wouldn’t it be better if that fat would never be got it?
Add Rector in CI in 3 Steps
1. Install Rector
composer require rector/rector --dev
2. Create rector-ci.yaml config just for code-reviews
# rector-ci.yaml parameters: sets: - "dead-code"
3. And add to your CI bash
vendor/bin/rector process src --config rector-ci.yaml --dry-run
How to add Rector CI to your Favorite CI?
I’ve prepared a demo with PHP code and a testing pipeline for all widely used CI services.
- GitHub Actions
- GitHub + Travis CI
- Gitlab CI
There you’ll find all the configuration you need to let your CI do code-reviews.
1. GitHub Actions 
# .github/workflows/php.yml name: Rector Code Review on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/[email protected] - name: Validate composer.json and composer.lock run: composer validate - name: Install dependencies run: composer install --prefer-dist --no-progress --no-suggest - name: Code Review run: ./vendor/bin/rector process --config rector-ci.yaml --dry-run
2. GitHub + Travis CI 
# .travis.yml os: linux language: php php: - '7.2' install: # install composer dependencies for all stages - composer install --prefer-dist --no-ansi --no-interaction --no-progress jobs: include: - stage: test name: "Tests" script: - vendor/bin/phpunit - stage: test name: "Code Review" script: - vendor/bin/rector process --config rector-ci.yaml --dry-run
3. Gitlab CI
# .gitlab-ci.yml # inspired from https://docs.gitlab.com/ee/ci/examples/php.html # see https://github.com/RobBrazier/docker-php-composer image: robbrazier/php:7.2 before_script: # install composer dependencies for all stages - composer install --prefer-dist --no-ansi --no-interaction --no-progress stages: - test tests: stage: test script: - vendor/bin/phpunit code-review: stage: test script: - vendor/bin/rector process --config rector-ci.yaml --dry-run
4. Bitbucket 
# bitbucket-pipelines.yml # see https://github.com/RobBrazier/docker-php-composer image: robbrazier/php:7.2 pipelines: default: - step: name: "Build" script: - composer install --prefer-dist --no-ansi --no-interaction --no-progress artifacts: - build/** - vendor/** - composer.json # beacause of scripts - composer # @see https://confluence.atlassian.com/bitbucket/parallel-steps-946606807.html - parallel: - step: name: "Tests" caches: - composer script: - vendor/bin/phpunit # Run Rector CI - step: name: "Code Review" caches: - composer script: - vendor/bin/rector process src --config rector-ci.yaml
What sets to Start With?
Here are my favorite sets I apply first:
# rector.yaml parameters: sets: - 'coding-style' - 'code-quality' - 'dead-code' - 'nette-utils-code-quality'
But you don’t have to stop there. Pick any of 103 sets that Rector provides. E.g.:
# rector.yaml parameters: sets: - 'php70' - 'php71' - 'php72' - 'php73' - 'php74'
Oh… one more thing. You don’t have to resolve all the Rector reported flaws manually, just remove the –dry-run option and run it locally before pushing:
vendor/bin/rector process src --config rector-ci.yaml
Enjoy your coffee!
This article first appeared on Tomas Votruba’s blog: https://www.tomasvotruba.com/blog/2019/11/18/how-to-delegate-code-reviews-to-ci/