L'utilisation d'un ORM efficace comme celui de Django abstrait la base de données au point de rendre parfois le debug malaisé voire difficile. Il n'est pas souvent évident de remonter jusqu'à la vue qui a généré une requête SQL consommatrice de ressources qui aurait été détectée dans les logs d'un …
Using Github CODEOWNERS file
Thu 12 April 2018 • Tags: githubIntroduction
GitHub CODEOWNERS file is a simple way to automate away some of the pain associated with the review system on github, by automatically assigning reviewers to a pull request based on which files were modified.
How to use
It's really simple ! Just drop a file named CODEOWNERS either at the root of your repository, or in a .github folder.
The simplest file you can use is as follows:
* @user1 @user2
This will automatically add user1 and user2 to any PR created on the repository.
When several patterns match the same file, the last one is taking precedence. This allows to ask reviews from the right team for any file, as illustrated by this example on a project structure similar to what we use:
# These owners will be the default owners for everything in
# the repo.
* @peopledoc/<project>-developers @peopledoc/<project>-po
# Dot-files should be handled by the lead dev (.gitignore and co)
.* @peopledoc/<project>-leaddev
# Frontend assets
*.js @peopledoc/tribe-js
# Template and assets
*.html *.css *.scss *.img @peopledoc/tribe-ui
# Some module is quite complex, and shouldn't be touched without an expert
# chiming in
some_module/tricky_part/*.py @functional_expert1 @functional_expert2
# Schema and SQL migrations
*.sql *-ddl.pg @peopledoc/dba
# QA
/tests/end2end/ @peopledoc/set
# Copywriting
*.po @peopledoc/localization-manager
# Devsec
/ansible/credentials/ @peopledoc/devsecops
The only one surprising thing is that reviewers are not added while you're creating the PR, but only once it's been created.