You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+68-9Lines changed: 68 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
4
4
5
-
## Environment setup
5
+
## __Environment setup__
6
6
7
7
First install dependencies and setup pre-commits hooks
8
8
@@ -20,9 +20,9 @@ To add a dependency use poetry
20
20
poetry add <dependency>
21
21
```
22
22
23
-
## Dev
23
+
## __Dev__
24
24
25
-
### Code
25
+
### __Code__
26
26
27
27
First open an issue to discuss the matter before coding.
28
28
When your idea has been approved, create a new branch `git checkout -b <new_branch_name>` and open a Pull Request.
@@ -34,13 +34,52 @@ make check
34
34
make test
35
35
```
36
36
37
-
##Commits format
37
+
### __Commits format__
38
38
39
39
Commits format is enforced according to the tool https://github.com/lumapps/commit-message-validator
40
40
41
-
A pre-commit hook as well as an action will check that for you and PR need to respect that format to be merged.
41
+
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
42
42
43
-
### Documentation
43
+
```
44
+
<type>(<scope>): <subject>
45
+
<BLANK LINE>
46
+
<body>
47
+
<BLANK LINE>
48
+
<footer>
49
+
```
50
+
51
+
* The first line of the commit message (the "Subject") cannot be longer than 70 characters.
52
+
* Any other line of the commit message cannot be longer 100 characters!
53
+
* The body and footer are optional, but depends on the type, information can be mandatory.
54
+
55
+
This allows the message to be easier to read on github as well as in various git tools.
56
+
57
+
58
+
**Type**
59
+
60
+
Must be one of the following:
61
+
62
+
* feat: A new feature
63
+
* fix: A bug fix
64
+
* docs: Documentation only changes
65
+
* lint: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc)
66
+
* refactor: A code change that neither fixes a bug or adds a feature
67
+
* test: Adding missing tests or correcting existing tests
68
+
* chore: Changes to the build process or auxiliary tools and libraries such as distribution generation
69
+
70
+
Example:
71
+
```
72
+
feat(toto-service): provide toto for all
73
+
74
+
Before we had to do another thing. There was this and this problem.
75
+
Now, by using "toto", it's simpler and the problems are managed.
76
+
```
77
+
78
+
> More: For more informations about the commit format see [here](https://github.com/lumapps/commit-message-validator#commit-message-format)
79
+
80
+
>Note: A pre-commit hook as well as an action will check that for you and PR need to respect that format to be merged.
81
+
82
+
## __Documentation__
44
83
45
84
Additionnaly to edit the documentation you can add/modify markdown files in the docs folder.
46
85
You can preview the doc by running
@@ -49,13 +88,33 @@ You can preview the doc by running
49
88
make docs-serve
50
89
```
51
90
52
-
Then to deploy the doc you cna run
91
+
Then to deploy the doc you can run
53
92
54
93
```bash
55
94
make doc-deploy
56
95
```
57
96
58
97
59
-
## Deploy to pypi
98
+
## __Deploy a new version (admins)__
99
+
100
+
101
+
### __Regular release__
102
+
103
+
Simply create and push the tag X.Y.Z on master.
104
+
105
+
```
106
+
git tag X.Y.Z
107
+
git push origin master X.Y.Z
108
+
```
109
+
110
+
This will create a draft release, you'll then need to publish it.
111
+
112
+

113
+
114
+
Finally the CI will release the corresponding package version on Pypi, bump the version and publish the doc for you.
115
+
116
+
### __Beta release__
117
+
118
+
Doing a beta release is a bit different, we do not use tag automation for the time being.
60
119
61
-
When a tagged is pushed the ci will create a release draft and then another workflow will be trigger that will deploy to pypi the version tagged and also deploy the documentation
120
+
Simply publish a pre-release on github with the correct tag (eg, 1.1.3b1) and this will trigger the publication on Pypi
0 commit comments