The 5GTANGO Gatekeeper V&V Platform specific components repository
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

Build Status Join the chat at

Verification & Validation platform-specific Gatekeeper component

This is the 5GTANGO Gatekeeper Verification and Validation platform specific components repository, which closely follows its SP Platform counterpart, complementing the common component repository .

Please see details on the overall 5GTANGO architecture here. The Gatekeeper is the component highlighted in the following picture.

Installing / Getting started

This component is implemented in ruby, version 2.4.3.

Installing from code

To have it up and running from code, please do the following:

$ git clone # Clone this repository
$ cd tng-gtk-vnv # Go to the newly created folder
$ bundle install # Install dependencies
$ PORT=5000 bundle exec rackup # dev server at http://localhost:5000

Everything being fine, you'll have a server running on that session, on port 5000. You can use it by using curl, like in:

$ curl <host name>:5000/

Installing from the Docker container

In case you prefer a docker based development, you can run the following commands (bash shell):

$ docker network create tango
$ docker run -d -p 27017:27017 --net=tango --name mongo mongo
$ docker run -d -p 4011:4011 --net=tango --name tng-cat sonatanfv/tng-cat:dev
$ docker run -d -p 4012:4012 --net=tango --name tng-rep sonatanfv/tng-rep:dev
$ docker run -d -p 5000:5000 --net=tango --name tng-gtk-vnv \
  -e CATALOGUE_URL=http://tng-cat:4011/catalogues/api/v2 \
  -e REPOSITORY_URL=http://tng-cat:4012 \

With these commands, you:

  1. Create a docker network named tango;
  2. Run the MongoDB container within the tango network;
  3. Run the Catalogue container within the tango network;
  4. Run the Repository container within the tango network;
  5. Run the V&V-specific Gatekeeper container within the tango network, with the CATALOGUE_URL and REPOSITORY_URL environment variables set to the previously created containers.


This section covers all the needs a developer has in order to be able to contribute to this project.

Built With

We are using the following libraries (also referenced in the Gemfile file) for development:

  • puma (3.11.0), an application server;
  • rack (2.0.4), a web-server interfacing library, on top of which sinatra has been built;
  • rake(12.3.0), a dependencies management tool for ruby, similar to make;
  • sinatra (2.0.2), a web framework for implementing efficient ruby APIs;
  • sinatra-contrib (2.0.2), several add-ons to sinatra;
  • sinatra-cross_origin (0.4.0), a middleware to sinatra that helps in managing the Cross Origin Resource Sharing (CORS) problem;

The following gems (libraries) are used just for tests:

  • ci_reporter_rspec (1.0.0), a library for helping in generating continuous integration (CI) test reports;
  • rack-test (0.8.2), a helper testing framework for rack-based applications;
  • rspec (3.7.0), a testing framework for ruby;
  • rubocop (0.52.0), a library for white box tests;
  • rubocop-checkstyle_formatter (0.4.0), a helper library for rubocop;
  • webmock (3.1.1), which alows mocking (i.e., faking) HTTP calls;

These libraries are installed/updated in the developer's machine when running the command (see above):

$ bundle install


We usually use rbenv as the ruby version manager, but others like rvm may work as well.

Setting up Dev

Developing this micro-service is straight-forward with a low amount of necessary steps.

Routes within the micro-service are defined in the file, in the root directory. It has two sections:

  • The require section, where all used libraries must be required (Note: controllers had to be required explicitly, while services do not, due to a bug we have found to happened in some of the environments);
  • The map section, where this micro-service's routes are mapped to the controller responsible for it.

This new or updated route can then be mapped either into an existing controller or imply writing a new controller. This new or updated controller can use either existing or newly written services to fullfil it's role.

For further details on the micro-service's architecture please check the documentation.

Submiting changes

Changes to the repository can be requested using this repository's issues and pull requests mechanisms.


The most up-to-date version is v4. For the versions available, see the link to tags on this repository.


The configuration of the micro-service is done through just two environment variables, defined in the Dockerfile:

  • CATALOGUE_URL, which should define the Catalogue's URL, where test descriptors are fetched from;
  • REPOSITORY_URL, which should define the Repository's URL, where test plans and test results are fetched from;


Unit tests are defined for both controllers and services, in the /spec folder. Since we use rspec as the test library, we configure tests in the spec_helper.rb file, also in the /spec folder.

To run these tests you need to execute the follwoing command:

$ CATALOGUE_URL=... REPOSITORY_URL=... bundle exec rspec spec

Wider scope (integration and functional) tests involving this micro-service are defined in tng-tests.

Style guide

Our style guide is really simple:

  1. We try to follow a Clean Code philosophy in as much as possible, i.e., classes and methods should do one thing only, have the least number of parameters possible, etc.;
  2. we use two spaces for identation.

Api Reference

We have specified this micro-service's API in a swagger-formated file. Please check it there.


This 5GTANGO component is published under Apache 2.0 license. Please see the LICENSE file for more details.