powrap automatically on automerge

[vpoulailleau]

During the last 30 days, 30 PR mention powrap in their comments.

Couldn't we use something like git hooks or github actions to use powrap automatically? This would reduce PR round trips.

BTW, powrap doesn't seems easy to install on Windows for beginners, so having this tool server side would be better. Or maybe client side with a fallback to no check at all if powrap is not installed.

What do you think?

[Seluj78]

I love the idea !

[JulienPalard]

Also it would be interesting to understand why we have wrapping issues in the first place, could it be just because of github suggesitons? I expect most newcomers to just use poedit, so they should never have wrapping issues in the first place.

[vpoulailleau]

because of github suggesitons?

Some of the wrapping errors come from that. I haven't checked in detail…

[Seluj78]

yes, I think 90% of the wrapping issues come from github suggestions. The rest are from people who sometimes forget to powrap after a quick vim edit like I often do

[JulienPalard]

I would like to test it: let's stop using github suggestions from a month or two, on first-timers PRs, just to check if it goes better?

I bet also github suggestions are hard for newcomers as they have to git pull them, which is not that easy for newcomers.

@Seluj78 @vpoulailleau @awecx @christopheNan @entwanne?

[entwanne]

Yes I agree, we should avoid suggestions as they can break the line-wrapping (or correcty format the suggestion to ensure the wrapping).

But an automatic run of powrap would also be great.

[awecx]

I agree that probably more than 90% of wrapping errors come from Github.
Let's list the stuff :

Pros of using Github suggestions:

• super effective to point out mistakes into translations, no need to write long explanations for simple stuff.
• super effective to ensure the suggestions have been applied by the translator. When a suggestion is accepted, the remark is closed automatically. This won't be the case anymore and I've seen lots of newcomers actually expecting the reviewer to close it.

Con of using Github suggestions:

• you have to pull the changes.
• it breaks wrapping.

I'd say the pros overwhelm the cons. Plus we can fix the wrapping issue by maybe … removing wrapping checks on Travis. Since most of the translators use poedit, we'll probably end up with less than 5% of lines incorrectly wrapped. We could rewrap them all at once from time to time.

That being said, as a scientist, I'm 100% into running experiments, so 👍 for trying @JulienPalard suggestion for some time.

[vpoulailleau]

super effective to ensure the suggestions have been applied by the translator

👍

we'll probably end up with less than 5% of lines incorrectly wrapped. We could rewrap them all at once from time to time.

👍

But an automatic run of powrap would also be great.

👍 (even if this is not done per pull request but on a, say, monthly basis)

That being said, as a scientist, I'm 100% into running experiments, so +1 for trying @JulienPalard suggestion for some time.

I'm not against the fact to try, but I think that @awecx is right saying "I'd say the pros overwhelm the cons" of GitHub suggestions.

[JulienPalard]

I'd say the pros overwhelm the cons.

Same. I'm proposing to only test (not using it) on first timers, so we should not really loose the pros.

And we do not need to all do the experiment to get some results, as currently only one of us should comment on a single PR at a time.

[deronnax]

(why the fuck do we speak english here ?!)
Je vais tenter de livrer un truc d'ici la fin du confinement, d'autant plus qu'on utilise pas mal l'API Github ici à Doctolib.

Pour le nom du botte, je voudrais l'appeler Molière ou Voltaire, ça vous va ?

Une idée proche : pas mal d'erreur de pospell dont des erreurs toutes bêtes genre un mauvais accent ou une seule mauvaise lettre. Je suis sûr qu'une lib open-source genre grammalecte ou même genre pourrait auto-corriger cela. Mais là, c'est tout de même un autre niveau.

[vpoulailleau]

Ce matin j'ai fait une GitHub action pour reformatter du C avec clang-format (du coup ça m'évoque le parallèle avec powrap pour des *.po) : ça push un reformattage si nécessaire.

Ça peut être un point de départ.

Dans .github/workflows/custom_ci.yml :

name: Custom CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2

    - name: run custom script
      run: $GITHUB_WORKSPACE/continuous_integration/format.sh
    
    - name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}

Et dans /continuous_integration/format.sh :

#!/bin/bash

if clang-format --version; then
    echo "found clang-format installation"
else
    echo "missing clang-format"
    sudo apt install clang-format
    # then assume the installation is correct
fi

THIS_SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
cd $THIS_SCRIPT_DIR/..  # go to root folder


FILES=`find . | egrep "\\.(c|h|cpp|hpp)$"`
for FILE in $FILES
do
    echo $FILE

    # format file
    clang-format -style="{BasedOnStyle: LLVM, IndentWidth: 4}" -i $FILE
done

# commit modification if any
git config --local user.email "vpoulailleau@gmail.com"
git config --local user.name "vpoulailleau"
git commit -a -m "code auto-formatting" || true