How to configure to use with Odoo git format?

[vonpupp]

Greetings,

I just stumbled with this cool package. I would like to use it to automatically parse the git history according to the Odoo guidelines. Herewith an example.

From what I have understood on the config file, I should be able to modify the behavior by changing the section_regexps, something as follows:

section_regexps = [                                                                                                                                                                
    ('New', [                                                                                                                                                                      
        r'^\[ADD\]\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',                                                                                                             
     ]),                                                                                                                                                                           
    ('Changes', [                                                                                                                                                                  
        r'^[cC]hg\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',                                                                                                              
     ]),                                                                                                                                                                           
    ('Fix', [                                                                                                                                                                      
        r'^\[FIX\]\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$',                                                                                                             
     ]),                                                                                                                                                                           
                                                                                                                                                                                   
    ('Other', None ## Match all lines                                                                                                                                              
     ),                                                                                                                                                                            
                                                                                                                                                                                   
]

Unfortunately this doesn't work as I would expect. Could you please guide me further?

Thank you very much.

[vaab]

Hmm, what tags are you using ? At a first glance, odoo is using tags and branch in a very peculiar way (the reverse of what is usually done)... Can it be the cause ? I'll have a deeper look here. And if we identify a nice new way to identify releases, why not. But it really seems that Odoo do not have stable releases (10.0 does not identify something installed on a computer or packaged at some very specific point in time). Which might have a lot of bad consequences other than simply making stable changelog's conceptually impossible.

For your information, for now, gitchangelog only uses tags to refer to releases. It wouldn't be a big leap to make this more customizable and be able to refer to branches. If you are writing a module for odoo, you can probably use a saner way to properly tag your releases. If you have a link to a github repository doing so, please send an URL so I can test.

[vonpupp]

Thank you @vaab.

Please take a look at the Odoo repo itself. It is worth also to have a look at the [Odoo Community Association (OCA)] organization, which maintains a vast amount of modules.

Odoo's modules uses a branch for the major release (8, 9, 10, and the coming soon 11). There is not a master branch. This might look wrong at first, but keep in mind that the software lives for long time, and ports/backports are often needed.

What I am personally focusing on is to have at least a way to parse git logs and generate a changelog even if it is without tags for now. The tags are: [IMP], [FIX], [REF], [ADD], [REM], [MOV], [MERGE], [CLA] all of them with brackets included.

Some git message examples would look like this:

[FIX] website, website_mail: remove unused alert div, fixes look of input-group-btn

Bootstrap's CSS depends on the input-group-btn
element being the first/last child of its parent.
This was not the case because of the invisible
and useless alert.

[IMP] fields: reduce memory footprint of list/set field attributes

[REF] web: add module system to the web client

This commit introduces a new module system for the javascript code.
Instead of using global ...

[vaab]

This might look wrong at first, but keep in mind that the software lives for long time, and ports/backports are often needed.

Well, isn't that the case of all softwares ? Tags are there to pin out releases to identify a static published version of the code. This is to identify for example what was installed exactly on a customer's side, which is of utter importance to know if that fix or this feature was included or not.

Let's come back to your goal "to have at least a way to parse git logs and generate a changelog even if it is without tags for now":

If you can you define me a way to group sequences of commits without tags, we can have something like a changelog. What I can come up with would be groups per unit of time as last commits per day, per week, per month for instance... or by arbitrary numbers of N commits. We can also think about taking the merge-base between these awkward version branches, but as I recall, it would be very arbitrary sectioning as the merge history of odoo was a huge spider web with no real meaning for a long time AND this would make HUGE sections, with a first HUGE list of fix, followed by a HUG list of changes... and so on.

We can't just remove sectioning at this high level for the same reason : I guess you don't want a very very very long list of all the fixes since the beginning of time, followed by the list of all changes ... etc ...

To be more clear on what you need as output (and come up with the answers I'm missing to fully understand your idea), I think it would be nice for you to sketch out a dummy example of the output you want. Don't forget to give a sample of a dummy git log as a way to sho me the state of the input repository, I am curious about the main sections you'll come by (the final sections that are fix/imp/ref are not a problem... ).

BTW, you insist on me to have a look again to links you already provided me in first post : I did already followed them all, and your example is a copy-paste of the guideline pages. It happens also that I know odoo quite well because I develop on it as well, for instance I developed the base of the new web calendar you are probably using, and it was incorporated as is in OpenERP's code, and I am still credited as co-author of this).

[vonpupp]

Thank you for your answer @vaab, I apologize for the misunderstandings.

I guess an output by start/end time would be useful. Imagine the following tig output:

2017-04-19 20:14 vonpupp o [ADD] Pin ipython version
2017-04-19 11:14 vonpupp o [FIX] Comment brazilian modules
2017-03-25 08:37 vonpupp o [WIP] Add OCA modules for boleto
2017-03-22 00:26 vonpupp o [ADD] l10n_br_account dependencies
2017-03-21 22:58 vonpupp o [ADD] Pyboleto, cnab, num2words for l10n_br
2017-03-19 23:13 vonpupp o [IMP] Certificate
2017-03-19 23:09 vonpupp o [ADD] Self-signed certificate
2017-03-19 23:07 vonpupp o [ADD] Systemd unit example
2017-03-19 23:07 vonpupp o [ADD] Nginx static files
2017-03-19 22:49 vonpupp o [ADD] Variables
2017-03-19 19:18 vonpupp o [REF] Reorganize nginx configs to look-alike
2017-03-19 17:20 vonpupp o [ADD] Nginx on buildout
2017-03-17 09:43 vonpupp o [ADD] Addons

For instance a gitchangelog --from-date=17/03/2017 --to-date=19/04/2017 could produce something like this:

From: 17/03/2017, to: 19/04/2017
------------------

Add
~~~
- [ADD] Pin ipython version. [vonpupp]
- [ADD] l10n_br_account dependencies. [vonpupp]
- [ADD] Pyboleto, cnab, num2words for l10n_br. [vonpupp]
- [ADD] Self-signed certificate. [vonpupp]
- [ADD] Systemd unit example. [vonpupp]
- [ADD] Nginx static files. [vonpupp]
- [ADD] Variables. [vonpupp]
- [ADD] Nginx on buildout. [vonpupp]
- [ADD] Addons. [vonpupp]

Fix
~~~
- [FIX] Comment brazilian modules. [vonpupp]

Imp
~~~
- [IMP] Certificate. [vonpupp]

Ref
~~~
- [REF] Reorganize nginx configs to look-alike. [vonpupp]

Wip
~~~
- [WIP] Add OCA modules for boleto. [vonpupp]

Another idea that could be interesting is to use regex on tags. Imagine that a module has 3 branches: 8.0, 9.0 and 10.0 and has tags following something like this:

• 8.0-2017-03-10-13-31
• 9.0-2017-03-10-13-31
• 10.0-2017-03-10-13-31
• 10.0-2017-05-12-14-52

For instance a `gitchangelog --tag-regex='10.0-*' could produce something similar to the original output of the readme only for tags starting with 10.0. Something like:

10.0 (2017-05-12-14-52)
------------------

Add
~~~
...

Fix
~~~
...

10.0 (2017-03-10-13-31)
------------------

Add
~~~
...

Fix
~~~
...

Another option would be using semantic versioning for tags, something like:

• 8.0-1.0.4
• 9.0-1.0.1
• 10.0-0.9.1
• 10.0-1.0.0

Same tag-regex idea applies though.

I guess Odoo S.A. internally must use something internally to achieve this (and I guess this is why they use this git format), but I don't know for sure, it is just a guess.

[vaab]

Thanks a lot, I think we can do things here.

Your second idea is already supported (because you add the pre-condition of having tags, which solves the main problem here). Nothing needs to be added to gitchangelog for this to work "tag_filter_regexp" is already in config file, and gitchangelog command line arguments are git revs (valid revs following rev-specs), so you could do a gitchangelog 10.0-2017-03-10-13-31..10.0-2017-05-12-14-52 with no issue.

To lighten the constraint of having a pre-condition, we could implement in gitchangelog a dynamical function that would infer changelog's release sectionning from a free form function. For now, this is fixed and is infering the release sections from the git tags. So, this would allow to create sections even if you don't use tags as odoo does. However you'd have to write your implementation of this function so as to define what is a section for you.

Another issue with that last idea is that we then introduce a discrepancy as currently, sections in changelog are actual REVS understood by git, and used directly as arguments of gitchangelog. So, to keep this interesting property, we could leave git describe NAME the sections.

To resume my thoughts, we would:

• remove tag_filter_regex in favor of a release_commit_filter option
• that function would provide the default value of GitTagRegex(..)... a function that would output a list all git tags and filter them with a regex.
• You could replace this function with any function that would output a list of commits symbolizing a specific point in history that will be used to segment the end changelog.
• This function would have access to gitrepository object to fiddle with it as it wants.
• The output of the function are only commits, and gitchangelog would ask to git describe --tags how to get a nice representation that is still a valid REVs so we can display it as name of the release.

What do you think about this ? Do you feel I have carefully taken into account all of your ideas ? I know my solution is not perfect and probably do not cover all aspect of your problem, but would it help ?

[vonpupp]

Thank you @vaab. Sounds good to me, however it is not clear how difficult would be to write this function to infer the changelog's release sections. If you could please provide some sort of example of the configuration and the function it would help to clarify. This would include also the time range parameters?