Gaia-X thrives on open-source and happily welcomes any contributions on software. The technical stack is mostly composed of NestJS typescript microservices. A few libraries and a few Quarkus microservices are also living in the repositories. These microservices can be deployed using Helm charts that are provided alongside them.
Developers
Home »
The main software components in the eco-system are the ones under the compliance directory.
1. COMPLIANCE ENGINE
The compliance engine is a NestJS Node 21 application. Its main task is to ingest VerifiableCredentials and return to the user their Label if they are compliant with the Gaia-X rules.
2. NOTARY
The notary serves in the ecosystem to validate the legal existence of a company using different sources such as the European Commission VAT ID API or the EORI database.
3. REGISTRY
The registry is the source of truth for the whole Gaia-X participants. It contains the SHACL shapes allowing to validate the structure of the JSON-LD payloads as well as the allowed certificate to be used to sign credentials.
4. IPFS PINNING SERVICE
This service is responsible of pinning (ie make accessible) on IPFS the different documents required for the Gaia-X framework, such as the Trusted Anchors list mentioned below, but also the list of accredited GXDCH and the complete ontology, including the SHACL shapes and JSON-LD schemas.
5. TRUSTED LIST SERVICE
This tool is responsible for gathering the trusted anchors specified in the Compliance Document providing them to Participants and tools, and to output them in a TrustedList in the ETSI 119 612 format. Its CI contains scripts that runs it, and pushes the result into the IPFS pinning service.
General concepts
Gaia-X adheres to several principles for the development.
Git branches
The lab has adopted a lightweight git flow for the management of the branches. All the features, fixes are developed from a branch-off from development. After review, the new code is tested and deployed to main if stable. From there, the release process takes place. The lab also takes care of several versions in parallel for maintenance purposes. At the moment, the v2 is under development, thus uses development and main branches. A v1 branch is kept for maintenance of v1.
Continuous deployment
Each principal branch is deployed automatically after tests, linting and Sonarqube have run successfully on the branch. This means that the lab provides a deployment for development, main, v1 and v2.
Conventional commit
In order to maintain a good quality history, the lab uses conventional commit. These commits are also used during the release process to generate the changelog, and proceed to an eventual version number change.
For the sake of traceability and liability, we also ask contributors to add the Signed-off-by tag at the end of the commit message.
Semantic-release
The lab uses Semantic-release to take care of the release management. This tool takes in account all the commits since the last release, and bump the version number accordingly to the following: chore, docs do not trigger a release. fix will trigger a fix version change, feat will trigger a minor version change, and any commit containing BREAKING CHANGE: will trigger a major version change.
Semantic-release takes care of creating the changelog, create the git tag, bump the version in the package.json files, and back-merge the commit on the development branch.