A package is a collection of directories, assemblies, scripts, and steps. A step can be configured to run a command file/exe, a script or a test runner (Nunit or Visual Test Console).
Once a package was defined, Korredo keeps its definition on disk under the Packages folder. The packages can be modified, copied or deleted at any time.
Using the definition from a package level, Korredo creates an archive file with the specified directories. This archive is then sent to all available agents and each agent executes the package based on the defined scripts and steps. In the end, the result of a package is sent back to the requester as a collection of artifact files.
The following image shows the form used to add/edit a package:
In this section, the user can configure the most important parts of a package: the source directories, the assemblies with tests, and the steps.
%environment% or %system% parameters can be used in all three sections. For more details please check this post
A new package can be quickly created by using the button Configure using the wizard which helps the user to add a source directory, an assembly and a step runner using only a few mouse clicks.
Custom init script
It’s a Windows bash script executed before copying the package and creating the archive. It can be used for example to delete the logs from the sourc folders or to compile the source code.
Custom cleanup script
It’s a Windows bash script used on each agent at the end when the package finishes his execution. It can be used to drop databases, copy files to the %system.ArtifactsFolder%s or kill known processes.
All agents configured in the Settings section/Known hosts tab will appear here as a list of checkboxes. The list is used to automatically select the available agents when the user Press Run on a package. If only some agents are selected, the package will run only on that agents. The user can always overwrite the package definition by manually selecting the agents where he wants to run the package.
A good example when this section is useful: Selenium tests can run only on AgentX.
Another example is when a package contains only unit tests, or integration tests that takes a small amount of time can be configured to run on “My agent” only. In case a package is shared as a template, the package will run only on the user’s machine.