Client Configuration

Client Configuration (remoteDifido.properties)

Connecting with the Difido server can be a powerful solution that can help teams share and organize the various execution results.

The remoteDifido.properties is a configuration file that is created in all the binders that can connect to the server, in most cases, at the root of the project. The file includes many options to integrate the systems and setting them can be a bit confusing, especially all the properties that are related to the shared executions.

In this page, I will try to shed some light on the subject.

Basic Configuration

To integrate the two systems, one should configure the basic connection properties. Those property are really self-explanatory. We have the host and port properties.

You can also decide to disable the integrations by setting the enable property to false

Execution Description and Properties

execution.description

The execution description will be added to the execution and will be displayed in the execution list table. If the description is not set, a generic name that includes the execution id, e.g. exec_42, will be assigned.

execution.properties

You can also add an open list of key value pairs (properties), to each execution. You can later search and sort your various executions using those properties.

The list is semicolon separated and can look something like this:

version=6.1.02;build=6546;user=Mocky

The properties will be displayed in the execution list unless the The server administrator decided to add properties filters.

Shared Executions

use.shared.execution

There are two kinds of executions, shared and not shared. Shared executions can be, as the name suggests, shared between a number of machines.

When execution is set to shared, and as long as it is active, you, and everyone else that are using the server can add additional reports to it. The execution will be active until the idle timeout that is configured in the server is reached or until it is set to be not active using the server API. When execution is no longer active, it can no longer set to active.

If you want your execution to be shared, or if you want to append some execution results to a single execution, set the use.shared.execution to true.

If the use.shared.execution is set to false, it will include only a single run and will be closed when the run is finished. No more executions can be appended to it.

force.new.execution

If you set your execution to be shared, your reports can be appended to any other execution that is shared in the system and it is still active, but in some cases, you want to create a shared execution and you want to make sure that this is a new execution.

In this case, configure the force.new.execution to true.

If you want to append your other reports to this execution, don't forget to set this option to false after the first run.

append.to.existing.execution and existing.execution.id

The combinations of this options is mostly handy when we want a number of machines to append results to a single execution and we have an external orchestrator, like a CI server, that can start and end the execution and also to publish the execution id to the various machines.

With this options, we can make sure that all the reports will be included in a single execution entry.

To use it, set the append.to.existing.execution option to true and set the existing.execution.id to the id of the execution you want all the reports to append to. Of course, this should be done by the orchestrator that started the execution and has this id.

You also need to make sure that the use.shared.execution is set to true and the force.new.execution is set to false. If you understand the previous explanations, you can probably understand why this is necessary.

The configuration should look something like this:

append.to.existing.execution=true
existing.execution.id=17
force.new.execution=false
use.shared.execution=true

Now, as long as there is an execution with this id and it is configured to be shared and it is in an active state, all reports will be appended to it, no matter how many active and shared executions exists in the server.