ci: Check that PR title follows conventional commit prefix

[untereiner]

The main objective is to be able to release easily. It is easier to compute version numbers based on conventional commits. But constraining every commit message may be too much. To make this process easy I propose to only constrain the merge commit message. It can be easily check via this github action.

The allowed prefixes are:

• feat: A new feature
• fix: A bug fix,
• docs: Documentation only changes,
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc),
• refactor: A code change that neither fixes a bug nor adds a feature,
• perf: A code change that improves performance,
• test: Adding missing tests or correcting existing tests,
• build: Changes that affect the build system or external dependencies (example scopes: cmake),
• ci: Changes to our CI configuration files and scripts (example scopes: github),
• chore: Other changes that don't modify src or test files,
• revert: Reverts a previous commit,

It is also possible to add your own prefixes…

In case of wrong prefix this stage of the ci will fail and print out the a list of allowed prefixes

https://www.conventionalcommits.org/en/v1.0.0/

[TotoGaz]

@rrsettgast @castelletto1 Could you please review this?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.74%. Comparing base (aabbe29) to head (4a86fa6).
Report is 87 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3043      +/-   ##
===========================================
- Coverage    55.75%   55.74%   -0.01%     
===========================================
  Files         1041     1041              
  Lines        88534    88534              
===========================================
- Hits         49358    49356       -2     
- Misses       39176    39178       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rrsettgast]

Won't this skip the builds on develop?

[untereiner]

I added an if to ensure this action runs only at PR state

[rrsettgast]

Hi @untereiner . Can you explain what situation we are trying to avoid with this change? For instance, you have a check on the PR title prefix, so now every pr must have a prefix from some set of prefixes? What is the set of allowed prefixes?

[untereiner]

@rrsettgast I updated the PR text

[rrsettgast]

perhaps we should have a new prefix: crappy_chore 😬

[untereiner]

What do we do then ? I really think it’s a light way to introduce order.
We can also try to add an action to check changes in the xml or rst tables and request the breaking changes symbol in the title.

[untereiner]

@rrsettgast can we give it a try ?

[rrsettgast]

@TotoGaz @wrtobin Can you give feedback on this? I am ok with this, and we can perhaps make custom labels to expand cases like feat to feature...

[TotoGaz]

@TotoGaz @wrtobin Can you give feedback on this? I am ok with this, and we can perhaps make custom labels to expand cases like feat to feature...

Let's try it! If it brings more cons than pros, then we can always remove it 🤷

[CusiniM]

isn't this a duplicate of what we were trying to do with labels? If we start using this I think we can get rid of some of the labels.

[untereiner]

@CusiniM labels are for CI triage and reviewer information. Here is a first step to automate the process of releasing incremental versions of the code.

[CusiniM]

@CusiniM labels are for CI triage and reviewer information. Here is a first step to automate the process of releasing incremental versions of the code.

yeah some labels have a clear CI function and others are used to triage issues. But, for example, to me having both a label bug and a prefix fix: for the same PR is unnecessary.

[TotoGaz]

yeah some labels have a clear CI function and others are used to triage issues. But, for example, to me having both a label bug and a prefix fix: for the same PR is unnecessary.

Note that one is for PRs, the other for issues?

[CusiniM]

yeah some labels have a clear CI function and others are used to triage issues. But, for example, to me having both a label bug and a prefix fix: for the same PR is unnecessary.

Note that one is for PRs, the other for issues?

well, I think that's how we intended them when we created them in the first place but there is no logic in github for this. It's not like you can define a set of labels only for issues and one only for PRs... In any case, it's not a big deal.