Commit Message

Syntax

Valid commit messages have the structure:

[product/sub-product]\[type]([scope]/): #[issue-number] [title] // This is the commit title
               // This blank line separates the commit title from the commit body
[body]         // This is the commit body. It CAN have multiple lines

**[variable]** are required variables that must be replaced in a final commit message (**[]** symbols must be removed)
// Comment are comments that must be removed in a final commit message

Rules

The following rules must be met for a commit message to be valid:

**[product/sub-product]** variable depends on the changes in your commit.

The products are as follows:

all                 // Multiple components. Triggers CI for all products.
airs                // Main Fluid Attacks website.
common              // Shared infrastructure resources and utilities across all components.
converses           // Fluid Attacks AI-based assistant.
defines             // Fluid Attacks Vulnerability Criteria.
flags               // CLI for runnning CSPM scanner.
forces              // Client-side DevSecOps agent.
integrates          // Fluid Attacks platform back-end.
labels              // SBOM library.
melts               // CLI for downloading client source code repositories.
observes            // ETL suites for data centralization and analytics.
observes-code-etl   // Source code extraction and processing.
observes-gitlab-etl // GitLab data processing.
observes-infra      // Infrastructure-related ETL tasks.
probes              // CLI for runnning DAST scanner.
spots               // CLI for runnning SCA scanner.
retrieves           // VSCode plugin.
skims               // Automatic vulnerability scanner.
skims-cspm          // lib_cspm module and its tests.
skims-sast          // lib_sast module and its tests.
skims-dast          // lib_dast module and its tests.
skims-sca           // lib_sca module and its tests.
skims-apk           // lib_apk module and its tests.
skims-ai            // skims-ai CLI.
sorts               // Sort files in a Git repository by their probability of containing security vulnerabilities.
views               // Fluid Attacks platform front-end.

By using a sub-product, you ensure the commit only triggers the pipeline for that specific area.

If you are working on a file in the root of the repository, outside all of these folders, use common.

**[type]** variable has to be one of the following:

chore  // Operational and maintenance tasks (including rotation)
feat   // New features and adding tests
fix    // Bug fixes (including reverts)
refac  // Internal code improvements without changing functionality (including style)

**[scope]** variable has to be one of the following:

front  // Front-End change
back   // Back-End change
infra  // Infrastructure change
build  // Build system, CI, compilers, etc (scons, webpack...)
cross  // Mix of two or more scopes
doc    // Documentation only changes

A Commit title must exist.
A Commit title must not contain the ’:’ character.
Commit title must have 60 characters or less.
Commit title must be lower case.
Commit title must not finish with a dot ’.’.
Commit title must reference an issue.
Commit title must be meaningful. Avoid using things like feat(build)[integrates]: #5 feature.
A blank line between commit title and commit body must exist.
A commit body must exist.
Lines in commit body must have 72 characters or less.

Possible combinations

Below is a table explaining all the possible combinations between types and scopes for a commit message (Types are columns, scopes are rows):

	chore	feat	fix	refac
front	Perform operational or maintenance tasks in the front-end	Add a new feature or tests to the front-end	Fix a bug, revert a change, or improve performance in the front-end	Improve or modify front-end code
back	Perform operational or maintenance tasks in the back-end	Add a new feature or tests to the back-end	Fix a bug, revert a change, or improve performance in the back-end	Improve or modify back-end code
infra	Perform operational or maintenance tasks in the infrastructure	Add a new feature or tests to the infrastructure	Fix a bug, revert a change, or improve performance in the infrastructure	Improve or modify infrastructure configuration
build	Perform operational or maintenance tasks in building tools	Add new feature to building tools, a new building tool or tests	Fix a bug, revert a change, or improve performance in the building tools	Improve or modify building tools
cross	Perform operational or maintenance tasks across multiple system parts	Add a new feature or tests affecting multiple scopes	Fix a bug, revert a change, or improve performance affecting multiple scopes	Improve or modify code across multiple scopes
doc	Perform operational or maintenance tasks in the documentation	Add new documentation	Fix a bug, revert a change, or improve performance in documentation	Improve or modify the documentation

Where:

chore: maintenance tasks.
infra: infrastructure changes.
build: building tools.
cross: multiple scopes.
doc: documentation updates.
NA is not applicable.

Recommendations

Try to itemize your commit body:

- Add feature X in file Y
- Run script Z
- Remove file A with B purpose

ETA

When your Merge Request is related to one area/issue that has an enumerable universe, i.e, we know with considerable certainty how many MRs are necessary to complete it, then you should use the following ETA model as a Merge Request message:

- Speed: A [parts] / B [time unit] = A/B [parts]/[time unit]
- TODO: C [parts]
- ETA: C / (A/B) = C/(A/B) [time unit]

**[parts]** should be replaced for the aspect that allows to quantify the progress of the area, which can be a number of issues, cases, files, tasks, etc.

**[time unit]** should be replaced for an appropriate unit of time that will be used to estimate an ETA, for example days or weeks.

**B** is the units of time that has passed since you started addressing the issues of the area, **A** is the total number of **[parts]** that have been submitted in such **B** time and **C** is the total number of **[parts]** that we know will resolve the issues of the area.

ETA Merge Request message example:

- Speed: 4 issues / 2 days = 2 issues/day
- TODO: 10 issues
- ETA: 10 / 2 = 5 days

Example

Here is an example of a compliant commit message:

integrates\feat(build): #13 add type_check

- Add type_check function
- Remove unnecessary print_output function