Welcome to the verigreen FAQ page

This page will try to answer frequently asked questions that we usually get from developers and DevOps teams implementing Verigreen.

Q: What is Verigreen?

A: Verigreen is a lightweight, server side solution for verification of git commits. It is a gated check-in process which will not allow any failed CI commit to go into an integration/release/any protected branch.we keep it green (hence the name).

Q: What happen if two or more users push their code at the same time?

A: Verigreen deals with multiple pushes at the same time by using an "optimistic" algorithm approach.it merges the different commits and runs verification for every push on top of the previous ones, by order of arrival.

Q: I'm getting an error message saying that my push was rejected

A: This is the right behavior. Every new push is being deflected by the pre-receive hook to the Verigreen service, which is running a verification process through the build/CI engine. After the verification completed successfully , Verigreen is pushing the commits to the original protected branch.

Q: How will I know if my commit has reached the source control server?

A: An email notification is sent to the committer with the final status of the push, including links to Verigreens UI, Jenkins job URL, commit message and a specific reason in case of a failure.

Q: How is Verigreen better than other gated check-in systems, like: Gerrit, ElectricCloud, etc.

A: There are a few solutions in the market that are based on gated check-in system. None of them is supplying the solution EG suggests. For example: Gerrit - No auto-merging to Release branch, Uses a separate repository, Jenkins-based-only solution exists. ElectricCloud - Offline build with developer’s code, No auto-merging to Release branch, Client-Based. MS Gated-Checkin - Proprietary, Relies on TFS, Pessimistic algorithm. Zuul - Gerrit-based (mainly), On-prem support is not indicated, Changes workflow (no direct work against release repository).

Q: If another user pushes his code on top of my build and my build failed, what will happen for the second build?

A: Verigreen is handling permutations for every scenario. If commit 'a' is running on the system and commit 'b' pushed while 'a' is running, then EG runs the verification of 'a+b'. If commit 'a' has failed, then 'a+b' is canceled and a new verification process is starting for 'b' commit alone.

Q: I use IntelliJ and don't see a message saying "Submitted to build by Verigreen" - just a reject message.

A: IntelliJ can be configured to show the client message by enabling "Version Control" panel. Go to: View → Tool Windows → Version Control.

Q: I got a TIME_OUT status, what does it mean?

A: Every process in the system has a timeout definition for getting the results from the CI system. If a response was not received in this period of time, then the TIME_OUT status is being set to the process. The timeout definition can be modified via the config.properties (jenkins.timeoutInSeconds). The retry button is then enabled. if you use it, a new verification process will start for the same commit.

Q: I got a GIT_FAILURE status, what does it mean?

A: A git failure can cause for multiple reasons. If this status is showing before the verification process started (no Jenkins URL is displayed), then it could be for the following reasons: There is a problem in connecting to the source control server. The git repository location is not defined correctly. There are no permissions for EG to push / fetch from / to the remote repository. In case the above status is showing after verification passed successfully, then that means the branch's Head has changed during the verification process. It could happen if : This process was triggered via the retry button after a new commit was pushed to the source control server. A permitted user pushed his code while the verification process was still running. In both cases, check if there is another process started by EG that handles this failure automatically.

Q: I got a TRIGGER_FAILED status, what does it mean?

A: TRIGGER_FAILED can happen in two scenarios: Part of the Jenkins params in the config.properties are incorrect which causes the collector to fail while triggering the job in Jenkins - this can usually happen when a new collector is being deployed. Problems in Jenkins (network, overload, etc.) which are causing Jenkins to receive error when trying to get information on the running job - the collector is checking every few seconds if there is a new information on the request (if the build started, finished, what status is it in etc.), in case of 'connection lost', the status is set to trigger failed.

Q: I got an email notification reporting on a git failure status but my code was still pushed.

A: Check EG UI and see that there is a new process started by EG that passed successfully. This new process is a merge between your code and a newer/older code that was dealt by EG.

Q: My process is showing as NOT_STARTED for a long period of time

A: If there is a process that is still running in the system and a newer process is with a failure status (in RED color) , then your new process will not start until the running process will end. Verigreen is based on an optimistic algorithm approach and is doing a merge between the different commits and tries to push all of the commits together. In case of a failure, a decision needs to be taken, from which head the new commit will start. If a running process has finished successfully, then the new commit becomes the new head. In case of a failure, the head will stay at the same location which the running process has started from.

Q: I verified that my code was pushed and saw another commit made by Verigreen

A: Every time that two or more processes are running in parallel, and those processes were triggered by different users, a merge commit is being done by Verigreen. This action is required because all the users started with the same head. Meaning - the first user creates a commit h + a, the second user creates a commit h + b (a is still running and therefore didn't get pushed). Every merge that will be done by these two commits (h + a + b) will resolve as a 'merge not committed'. Verigreen is handling this commit and pushing it without any interference to the user.