This section is divided into 2 parts, as reflected in Verigreen's general architecture:

1. Verigreen pre-receive hook - Responsible to trigger Verigreen when a new commit is trying to enter the repository
2. Verigreen service - the actual service which is responsible for processing the commit and allow/deny it from being merged to the protected branch

Verigreen Hook

This is the front door to what Verigreen is all about. The Verigreen flow, in the perspective of the hook, works like this: The hook flow is pretty straight forward and basically does the following:

1. Receives a vector or parameters as part of the git protocol for code push to a remote server
2. Checking the validity of parameters
3. Checking if there is information on this commit and acts upon the results
4. Starts Verigreen processing or rejects the commit per Verigreen queries
   All queries of Verigreen service and how it is being handled are shown in the next section

Verigreen Service (a.k.a. "Collector")

Verigreen is a clever state machine. We move from state to state based on decisions taken during the verification process. The decisions, in turn, are being decided according to the results of the actions we do in each state. In case of a failure we do one thing, and in case of a success we do something else. In addition, we have some constrains on this system made up of permission categories, network latency and such.

States

Being a state machine, it's important to explain the various states the commit item (CI) is in. Some of states are final [FS] and some are transition states [TS]. TS can turn into a FS, but not the other way around. All the states and their type (in []) are listed below:

1. [TS] NOT_STARTED
2. [TS] RUNNING
3. [TS] PASSED
4. [FS] PASSED_AND_PUSHED
5. [FS] PASSED_BY_CHILD
6. [FS] FAILED
7. [FS] TIMEOUT
8. [FS] TRIGGER_FAILED
9. [FS] MERGE_FAILED
10. [FS] GIT_FAILURE
11. [TS] FORCING_PUSH
12. [FS] FAILED_AND_PUSHED

For clarity, we will refer to the different states with their respective numbers form this point on. Before we draw the entire work flow of a commit Item in Verigreen, let’s look at the various states [TS] an item can be in and to which state it can move to. The convention will be the following : state n ----> ( array of optional next states separated by a comma) .

State 1 ------> (2,8,9,10).
State 2 ------> (3,5,6,7,8*) (8* is currently a bug in Verigreen. It will not remain that way for long).
State 3 ------> (4,9,10).
State 11 ------> (12,9,10).

As you can see, TS can move to another TS or to an FS.
FS, by definition, is immutable.

The first scenario we will describe is state number 1 - NOT_STARTED. We will describe how Verigreen behaves at this point when a commit enters the system.

Verigreen creates an entity we call Commit Item - will refer to it as CI. A CI is an object in Verigreen which the states mentioned above refer to it, so it can be in any of these states.

At the beginning, CI status = 1 (NOT_STARTED). Here is the first basic flow which takes place once a commit is entering the Verigreen system:

The scheduler is constantly checking for a CI with an undone state. Once it finds one, it passes it to the decision maker object which decides what is the next phase the CI should be moving to.
The next flow describes what will happen inside the decision maker object.

TBD