Using Github CODEOWNERS file


Introduction

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.

More articles

How to detect (western) language with Python


Various options to (western) language detection

In order to optimise a NLP preprocessing pipeline, or to be able to tag a batch of documents and to present a user only with results in their preferred language, it might be useful to automatically determine the language of a text sample.

This article presents various options to do so in Python, from custom solutions to external libraries. Each solution is evaluated according to three dimensions, accuracy in language detection, execution time and ease of use.

TimescaleDB


This article is about TimescaleDB, a postgreSQL extension, specialized in storing Time Series data. The purpose is being able to easily manage data coming almost sorted on a time dimension. Log or audit events for instance.

Why TimescaleDB ?

PostgreSQL 10 introduces a real partitioning scheme. Before that, users had to …

ANSIBLE_STDOUT_CALLBACK=debug


Un nouveau plugin de type stdout callback fait son apparition dans la release d'Ansible 2.2. Ce plugin est fortement inspiré du snippet qui a tourné quelques années dans la communauté Ansible sous le nom de human_log.py. On peut l'activer avec ANSIBLE_STDOUT_CALLBACK=debug et en appelant ansible-playbook avec -v …

LXC démystifié


Cet article décortique l'installation de LXC. Le but est de pouvoir créer des conteneurs qui ont accès à internet, et qu'on peut résoudre en nom-de-conteneur.lxc. Je vais faire de mon mieux pour avoir une approche aussi instructive que ludique, un petit peu dans le style du site du zéro …

Utiliser l'application_name de PostgreSQL avec Django


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 …

Django, l'ORM et l'optimisation


Comme vous le savez sans doute, les objets de type QuerySet sont lazy. C'est à dire qu'ils ne sont évalués qu'au tout dernier moment. En fait, ils peuvent même ne pas être évalués du tout. Ou au contraire être évalués à de nombreuses reprises.

Evidemment, pour de meilleures performances, on …

1 / 7