It is crucial to clarify that billing is conducted based on the date commits are merged into the configured branch within the platform, not their creation date. This approach ensures that code analysis begins from that particular moment forward.

Due to this, it's possible for the billing to include authors who didn't commit during the month being billed. This situation may arise when changes are made in branches prior to the final version (pre-release), and subsequently, these commits are integrated into the branch with an active continuous hacking service. It's important to note that the date we observe a commit may not coincide with its original authorship date.

Caution: Modifying the Git history may result in additional charges.

Author identification

Through this process, we obtain all the authors (individuals or bots) whose changes (additions, modifications, deletions) to the source code we observe as merged on a date within the previous month. To accomplish this, we rely on the Git history information of each repository, focusing solely on the branch configured within the platform. The diagram below illustrates the procedure necessary for generating the authors' report. The next subsections explain the details of author identification in simple terms.

Preliminary considerations

1. Git, a distributed version control system, providing the "change history" for code projects. It allows to
   
1. save versions of a developer's work through "commits";
   
2. track every change made, who made it, and when;
   
3. create branches to work on new features in isolation, then merge them into the main project.
   
2. Synchronization of the commit history from a Git repository with Fluid Attacks' Snowflake database.
   
3. Snowflake, providing Fluid Attacks a sole database where the complete and permanent history of all commits is stored. It is the single source of truth for all analysis.
   
4. DynamoDB, a component to store the hash of the last processed commit. This tells Fluid Attacks where to resume in the next run, which avoids slow and costly queries to Snowflake.
   
5. The unique commit identifier, to check if a commit already exists in Snowflake. The system uses a combination of group name, repository nickname and commit hash.
   

Process

1. Cloning: The system clones the latest version of the Git repository to ensure it has the most recent history.
   
2. Checking of the starting point: It is required to know the point from which new commits are registered:
1. The system queries DynamoDB to get the hash of the "commit of reference" (the last commit saved in Snowflake).
   
2. The system searches for the hash in the newly cloned repository's history to confirm that the history has not been altered.
   
3. Scenario 1: The commit of reference exists: In this most common and efficient scenario
   
1. The system finds the commit of reference in the history.
   
2. The system iterates through the Git history starting from the commit of reference and inserts only the new commits into Snowflake.
   
3. DynamoDB stores the hash of each newly inserted commit, updating the commit of reference.
   
4. Scenario 2: The commit of reference does not exist: This scenario is triggered if the Git history was rewritten, making the DynamoDB "marker" invalid. In this scenario
   
1. The process does not find the commit of reference, which indicates that the history integrity has changed.
   
2. To ensure no information is lost or duplicated, the system initiates a full synchronization:
   
1. It iterates through the entire Git history, from the first commit to the last.For each commit, it checks Snowflake (using 
   group name, repository nickname and commit hash) to see if it has already been recorded.
2. If a commit is not in Snowflake, the system inserts it.This method is slower than that in Scenario 1, but it is a measure that guarantees data consistency even when Git history is modified.
   
5. Author count: When billing a client, Fluid Attacks validates all the commits inserted into its database (Snowflake) during the corresponding month. The authors of these commits are counted (each author is counted only once), and the total determines the amount to be charged to the client.
   

Billing report generation

In this phase, the process involves eliminating duplicate commits and consolidating information gathered from all organization repositories. These lists include author names, the groups they have contributed to, commit IDs, and repository names, each providing an example for every author. Authors who contribute only to files outside the testing scope are excluded.

Note: In the process, a commit's uniqueness is determined by the absence of duplications in the information. This validation encompasses fields like the author's name, email, date of authorship, and message content. Any alteration in these aspects renders the commit eligible for billing inclusion.

Billing section in the organization