diff --git a/doc/git-conventions.md b/doc/dev/git-conventions.md similarity index 70% rename from doc/git-conventions.md rename to doc/dev/git-conventions.md index 6b39a06393c69fab46212356595d2bb475b78ebd..37bbd2abe5ad439b95a97e110835a9e8b443ca00 100644 --- a/doc/git-conventions.md +++ b/doc/dev/git-conventions.md @@ -4,13 +4,12 @@ The summary gives an overview of the rules described below. Reading it will help you to dive into the details. -- branch created from an issue must have your pseudo as prefix -- manually created branches must be named according to the template `type/description` +- Branches must be named according to the template `type/description` - draft work must be prefixed by "WIP" (work in progress) - the naming of final commits must comply with the template `[type] scope: action subject` - one should communicate with developers through dedicated spaces - integrating a contribution can only be done via a merge with `-no-ff` option and since the following critera are fullfilled - - branch up to date with `dev` branch + - branch up to date with `dev` branch (except hotfixes, see the hotfix section) - idiomatic code formatting, automated tests passed successfully - clean commit history, understandable and concise - contribution approved by a reviewer @@ -21,7 +20,7 @@ The summary gives an overview of the rules described below. Reading it will help Most of the time, you'll use the "create a merge request" button and Gitlab will name your branch. In that case, please prefix the name of -your branch with your Gitlab username and a slash, for example: +your branch with the branch type, for example: fix/issue-test @@ -42,9 +41,10 @@ Example: ## Branch type -- feature : add a feature, refactoring existing code, or fix a bug in `dev` branch. -- release : create a release -- hotfix : fix in a release branch +- feature : add a feature +- ref : refactoring existing code +- fix : fix a bug in `dev` branch +- hotfix : fix à bug in a stable release ## Naming commits @@ -99,6 +99,10 @@ Every time the `dev` branch is updated, you must rebase each of your working bra 4. When you don't have any conflict anymore after `git rebase --continue`, then the rebase succeeded. Then rebase a remaning branch. +To prevent accidental merge commits, we recommend that force the `--ff-only` option on the merge command: + + git config --global merge.ff only + ## When to push Ideally, you should push when you are about to shut down your computer, so about once a day. @@ -156,3 +160,29 @@ After an interactive rebase, your local git history is different that yours in G Now is time to go to Gitlab and re-check your commits. Wait for the Continuous Integration pipeline to finish (it lasts ±20min), and at last when it is done you can remove the "WIP" mention of your Merge Request and mention (with "@name") the lead developers to ask for a code review. + +## Workflow + +Il y a 3 types de branches permanentes : + +- La branche `dev`, c'est la branche par défaut (le tronc), toutes les contributions doivetn être mergées sur cette branche (à l'exception des hotfix). +- La branche `stable`, elle pointe toujours sur le tag le plus récent de la dernière version stable. Elle sert de repère pour la documentation nottament. +- Les branches de hotfix, au format `hotfix/x.y`. Une branche de hotfix pour une version `x.y` n'est créée qu'a partir du moment où il y a un correctif à livrer en production sur cette version `x.y` et que correctif ne peut pas attendre version suivante. + +There are 3 types of permanent branches: + +- The `dev` branch is the default branch (the trunk), all contributions must be merged to this branch (except hotfixes). +- The `stable` branch, it always points to the most recent tag of the latest stable release. It is used as a reference for documentation, in particular. +- The hotfix branches, in `hotfix/x.y` format. A hotfix branch for an `x.y` release is only created when there is a patch to be released to production on that `x.y` release that cannot wait for the next release. + +## Hotfix + +Si un bug bloquant se produit en production et nécessite un hotfix, ce dernier doit faire l'objet de 2 tickets et 2 branches : + +1. Le ticket original du bug, doit être traité sur une branche `hotfix/issue-number-or-bug-description` puis mergé sur la branche `hotfix/x.y`, où `x.y` désigne la version en production a ce moment là . +2. Un ticket de report doit être créé, il doit citer le ticket original et permet de tracer la correction du bug sur la branche `dev`. Si pour X raison le hotfix n'a pas lieu d'être reporté sur la branche dev, le ticket de repport doit expliquer pourquoi puis être cloturé. + +If a blocking bug occurs in production and requires a hotfix, the latter must be the subject of 2 issues and 2 branches : + +1. The original issue, must be processed on a `hotfix/issue-number-or-bug-description` branch, then merged to the `hotfix/x.y` branch, where `x.y` is the version in production at that time. +2. A carryover issue must be created, quoting the original issue and tracing the bug fix to the `dev` branch. If for any reason the hotfix does not need to be carried over to the `dev` branch, the carryover issue should explain why and then be closed. diff --git a/doc/.vscode/launch.json b/doc/dev/vscode/launch.json similarity index 75% rename from doc/.vscode/launch.json rename to doc/dev/vscode/launch.json index c2426e5d416419389ad81cb4ff5eece4adf72de4..6b64ffff14400a9f49fc66c99c8ff880f1a7a7bb 100644 --- a/doc/.vscode/launch.json +++ b/doc/dev/vscode/launch.json @@ -11,7 +11,8 @@ "program": "${workspaceFolder}/bin/duniter", "args": [ "direct_start" - ] + ], + "runtimeExecutable": "${env:HOME}/.nvm/versions/node/v10.19.0/bin/node" }, { "type": "node", @@ -19,9 +20,10 @@ "name": "Mocha CURRENT FILE", "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha", "args": [ - "--opts", "\"\"", + "--opts", "\"\"", "--timeout", "600000", "${fileDirname}/${fileBasenameNoExtension}.js" - ] + ], + "runtimeExecutable": "${env:HOME}/.nvm/versions/node/v10.19.0/bin/node" }, { "type": "node", @@ -30,7 +32,8 @@ "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha", "args": [ "${workspaceFolder}/test" - ] + ], + "runtimeExecutable": "${env:HOME}/.nvm/versions/node/v10.19.0/bin/node" } ] } \ No newline at end of file diff --git a/doc/.vscode/settings.json b/doc/dev/vscode/settings.json similarity index 76% rename from doc/.vscode/settings.json rename to doc/dev/vscode/settings.json index 4ab73bb74fa5aab4145d56b8d43d2d3d83fab3ae..fe28223bf959d0657edb0ea12711b4fb56b4bf62 100644 --- a/doc/.vscode/settings.json +++ b/doc/dev/vscode/settings.json @@ -1,11 +1,11 @@ { "files.exclude": { - "*.js": true, "*.d.ts": true, "*.map": true, "app/**/*.js": true, "app/**/*.d.ts": true, "app/**/*.map": true, "**/.git": true - } + }, + "rust-analyzer.checkOnSave.command": "clippy" } \ No newline at end of file diff --git a/doc/core_file_system.pu b/doc/graphs/core_file_system.pu similarity index 100% rename from doc/core_file_system.pu rename to doc/graphs/core_file_system.pu diff --git a/doc/validator-guide.md b/doc/test/validator-guide.md similarity index 99% rename from doc/validator-guide.md rename to doc/test/validator-guide.md index b7b37a2677f68cd1e585c8fa914fc57ac9599117..173a4b3e71f84e3ad90778ac3b44da88532ec9e1 100644 --- a/doc/validator-guide.md +++ b/doc/test/validator-guide.md @@ -73,7 +73,7 @@ Duniter should be able to resolve forks, i.e. switch on a branch that does not c > A technique to test this: > -> ``` +> ```bash > duniter reset data > duniter sync g1.duniter.org 443 > duniter gen-next --local-submit diff --git a/doc/docker.md b/doc/use/docker.md similarity index 100% rename from doc/docker.md rename to doc/use/docker.md