Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Introduction


This modules provides the mechanism to integrate with 3rd party Git Providers.



Objective


Repositories currently integrates with: Github - Bitbutcket & Bitbucket Enterprise.

The modules supports multiple account types: Public - Private & Organizations.

Once an account has been linked, the list of repositories is fetched and you can activate/deactivate its repositories accordingly.

By default, every new installation of SOAJS dashboard comes equipped with SOAJS's default account and have a set of repositories already activated but not shown:

Each repository contains the code of a ready made SOAJS products. Together, these product are deployed in Dashboard Environment and form the cloud of microservices you need to build, configure and deploy services, daemons and static content in all the other environments.

Activate and turn CI on Repositories.

Configure Cd on deployed repository service. 



Git Repositories


Git Repositories contain your code that can be categories as one of the 3 options below:

  1. Microservice
  2. Daemon
  3. Multi Repo

When activating a repository, the Dashboard attempts to load a config.js file from the root level of that repository and parse it to learn what this repository contains.

Once a repository is activated and based on what it contains, you will be able to see a new service/daemon.


Microservice


A microservice is a Restful HTTP server that contains APIs. Click here to see how to build a microservice.

If the repository contains only 1 microservice, then the config.js file should have a schema similar to:

Config Example for a microservice
'use strict';

module.exports = {
   type: 'service',			//type is service
   prerequisites: {
      cpu: '',
      memory: ''
   },
   serviceVersion: 1,
   serviceName: "example03",
   serviceGroup: "SOAJS Example Service",
   requestTimeout: 30,
   requestTimeoutRenewal: 5,
   servicePort: 4012,
   extKeyRequired: true,
   session: true,
   oauth:true,

   errors: {},
   schema: {
		//api list
	}
};

SOAJS needs the following properties to be static in order to identify it as a service :

KeyValue (example)
serviceVersion1
serviceNameexample03
serviceGroupSOAJS Example Service
servicePort4012


Daemon


A Daemon is nodeJS script that supplies jobs to be executed in a certain order. Click here to see how to build a daemon.

If the repository contains only 1 daemon, then the config.js file should have a schema similar to:

Config Example for a microservice
'use strict';


module.exports = {
	'type': 'daemon',			//type is daemon
	'prerequisites': {
   		'cpu': '',
   		'memory': ''
	},
	'serviceName': 'myDaemon',
	'serviceGroup': 'myDaemonGroup',
	'servicePort': 4177,
	'errors': {
	   	400: 'Mongo Database connection error',
		401: 'Error while executing Count Query.',
   		402: 'Model not found'	
	},
	'schema': {
		//job list
	}
};

SOAJS needs the following properties to be static in order to identify it as a daemon :

KeyValue (example)
serviceNamemyDaemon
serviceGroupmyDaemonGroup
servicePort4177


Multi Repo


A multi repo is a collection of any of the above.

If the repository contains a multi repo, then the config.js file should have a schema similar to:

Config Example for a multi repo
"use strict";

module.exports = {
   "type":"multi",
   "folders": [
      "mySrv1/", 	//service 
      "myDaemon/", 	//daemon
      "myUI/", 		//static content
      "mySrv2/"		//service
   ]
};



Activate and turn CI on Repositories 


Activate your needed repository then click the configuration button next to your repository.

Configure its settings and manage the environment variables that should be available at build time.

There is some predefined environment variables related to SOAJS, which are displayed in read only mode. Plus you can add some custom variables according to your needs.

You can only configure repositories which are activated, deployed in an environment other than dashboard, dependent to the same git owner and which you have access on git.

You can check the available CI provider recipe. In case you would like to use one of them, download it → extract it → add it to your repository and push it.

According to the repository branch you pick, we will check for a recipe and compare it with the available recipes.

To make CD functional, Download CD script, add it to your repository as well and push it to GIT. In this way, on any change, this script will run and act based on your CD configuration.

  • No labels