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.

This is a list of our current products:

all                 // Multiple components. Triggers CI for all products.
common              // Shared infrastructure resources and utilities across all components.
converses           // Fluid Attacks AI-based assistant.
defines             // Fluid Attacks Vulnerability Criteria.
designs             // Branding and design assets.
directs             // CLI for orchestrating components.
flags               // CLI for running CSPM scanner.
fixes               // Remediate vulnerabilities leveraging the power of GenAI.
forces              // Client-side DevSecOps agent.
inspects            // CLI for running APK scanner.
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 running DAST scanner.
retrieves           // VSCode plugin.
runs                // Core infrastructure for serving components.
skims               // CLI for running SAST scanner.
sorts               // Sort files in a Git repository by their probability of containing security vulnerabilities.
spots               // CLI for running SCA scanner.
views               // Fluid Attacks platform front-end.

This list may vary. To confirm the supported products, please visit our repository.

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
conf    // Configuration files change
job     // Asynchronous or schedule tasks (backups, maintenance...)
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 the commit title and the commit body must exist.
A commit body must exist.
Lines in commit body must have 72 characters or less.

Compliance with commit message rules is checked with Commitlint.

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):

Scope	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 the 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

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 with 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 with 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 have 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 in the area.

ETA Merge Request message example:

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

Examples

Here are some examples of compliant commit messages:

integrates\feat(build): #13 add type_check
- Add type_check function
- Remove unnecessary print_output function

observes-gitlab-etl\fix(back): #15676 due date type
- Adjust due date definition and decoder
- Commit: 5328be22

More about Common

Tip

Have an idea to simplify our architecture or noticed docs that could use some love? Don't hesitate to open an issue or submit improvements.

Commit Message | Development Standards | Fluid Attacks Help