Skip to content
This is the fork maintained by the European Commission DIGIT ISA Unit based on the work of the GITB CEN Workshop Agreement. The original version of this software is the GITB PoC hosted at
Java Scala CoffeeScript JavaScript HTML CSS Other
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

GITB Engine


GITB PoC Testbed implementation uses Maven as a build automation and dependency management tool. This project can be built by executing the following command within the root folder of the project:

$ mvn clean install -DskipTests=true

This command builds and compiles all necessary files and creates a war file located in the gitb-testbed-service/target/gitb-testbed-service-1.0-SNAPSHOT.war

Development environment

When making a development build, the URL for the test case repository needs to be set. This is done by providing environment variables as follows:

By default these are set to work with docker containers as defined in /gitb-remote-testcase-repository/src/main/resources/


GITB PoC Testbed implementation can be run after a successful build by executing the following command within the root folder of the project:

$ mvn jetty:run -pl ./gitb-testbed-service/


GITB PoC Testbed has a test control & management application located under gitb-ui folder. This project is an SBT project that uses Play! Framework.


GITB UI application assumes that the following tools are installed and running:

  • Redis
  • GITB Engine


The GITB-UI project can be configured using the parameters located in gitb-ui/conf/application.conf file.

HTTP Server

It listens 9000 port by default. However this can be configured by either setting http.port configuration in gitb-ui/conf/application.conf file or running the application with -Dhttp.port=${GITB_UI_PORT} parameter.

MySQL Database

For this application to work properly, the following DB configurations must be set in gitb-ui/conf/application.conf:

  • db.default.url="jdbc:mysql://localhost/gitb?characterEncoding=UTF-8&useUnicode=true&autoReconnect=true"
  • db.default.user=...
  • db.default.password=...
  • db.default.rooturl="jdbc:mysql://localhost/"

Redis Server

By default, it assumed that there is a Redis Server available at the address. This can be configured by setting the parameters in gitb-ui/conf/application.conf:

  • = ""
  • redis.port = 6379

GITB Engine

To run the tests, an instance of the GITB Engine should be up and running. The Testbed Service endpoint for the GITB Engine instance can be configured by setting the testbed.service.url parameter in gitb-ui/conf/application.conf.

User management

User roles

Currently, the following roles are implemented in the project:

  • Vendor Admin: Vendor system administrator
  • Vendor User: Vendor system user (tester)
  • System Admin: Manages the test engine, users, and repositories, creates new domains, specifications, deploys/removes test suites

System admins are created under organization with ID 0. So, a default organization with ID 0 should be available in the gitb.organizations table. This organization is otherwise fully hidden in the UI.

Build & Running

Since this application is using the Play! Framework, an executable that takes care of the build & running process exists in the application folder. To do these operations please execute the following commands in the gitb-ui directory:

  • ./activator clean compile to build the application
  • ./activator run to run the application in debug mode
  • ./activator clean dist to create a standalone distribution. This command creates a zip file located under gitb-ui/target/universal/ folder. You can unzip this file to the deployment folder. After this, there should be an executable script located in bin/gitb-ui path. This script can be executed directly to start the application in production mode.

These build commands are equal for both docker and local deployment. The application config file defaults to a local deployment and is working with environment variables for the docker container. This way no additional steps have to be taken depending for which deployment we are building for.

Test Suite Deployment

Currently only users with System Admin roles can deploy test suites. Test suites are deployed using zip files.

One of the critical things about the structure of the test suite archives is the test suite definition xml file. This file is formatted according to the TestSuite type defined in the gitb-tdl schema (ns: and it should be located at the root of the test suite archive.

After configuring a user as System Admin, when this user is logged in to the system Admin link appears at the top navigation bar.

To deploy a test suite, a domain and a specification related to the test suite must be created. Then, in the specification detail page, by using the Deploy test suite button, a test suite archived can be uploaded. If the deployment is successful, test cases and actors related to the test suite should be added to the system.



You can’t perform that action at this time.