# Populating your Service Catalog with Github and Datadog

## **Github**

Installation is done by using the Rely.io integration page where you'll be redirected to GitHub App's integration form. Login to your GitHub account and submit the form by providing the necessary permissions (official docs[ here](https://docs.rely.io/data-sources/integrations/github)). 

Once you’re done, rely will be able to ingest the repositories, issues, pull-request, and workflows that it has access to. Upon installation Rely offers OOTB automation rules to best map the assets that are discovered in Github into entities in your software catalog. This will allow you to populate and meaningfully link entities in your software catalog automatically. 

From this point forward you can either go with the out-of-the-box rules or if you are feeling adventurous you can tweak the settings to your liking. The output of these automation rules will look something like this in your service catalog:

<figure><img src="https://1179008450-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eBCWu9rFSzq3ahnNrmL%2Fuploads%2FU7xySZSacRQieeUwiYac%2Fimage.png?alt=media&#x26;token=a6d0afcd-bbbe-4be8-8125-aa476836f675" alt=""><figcaption><p>Service Catalog post Github installation</p></figcaption></figure>

### The default automation-rules for the Github plugin allow you to:

#### Import Github users into Rely that you later invite on-to the platform.

Having Users reflected as their own entity allows you to more easily keep track of ownership and activity even if they’re not an actual user in Rely just yet.

#### Import Github teams into Rely and automatically link them to their members & leaders according to the definitions in Github.

Import Repositories as Services and automatically link them to the teams, users, issues, pull-requests & workflows that have contributed to it, as well as to import relevant information like:

* The content of the README.
* The list of programming languages used in the repository.
* The number of open pull-requests & issues.

Such a Service will look more or less like this:

<figure><img src="https://1179008450-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eBCWu9rFSzq3ahnNrmL%2Fuploads%2FoPuvwcz2CxESfEqxVFAD%2Fimage.png?alt=media&#x26;token=c3fbd890-4c01-4b82-bc08-a9e1a080da72" alt=""><figcaption><p>Service Details Page post Github Installation</p></figcaption></figure>

#### Import Workflow Runs that specifically target the repositories main branch as “deployment” entities to the “production” environment.&#x20;

Worry not, if this isn’t a suitable way for you to identify deployments in your organization, you can easily adjust the automation rule to target workflows with a specific label, a specific name nomenclature, etc. This will automatically link the deployment to the service, the user who triggered it, the one who approved it, the team they belong to and bringing information like:

* When was the deployment triggered
* How long did it take
* The commit hash
* The final status of the workflow
* The commit hash
* A link to the respective workflow
* Etc.

## **Datadog**

To get Datadog installed into Rely.io you’ll need to create an Application key in Datadog with the necessary scopes and permission (official docs[ here](https://docs.rely.io/data-sources/integrations/datadog)) and paste them into the two-step wizard in Rely.io. Now Rely will be able to ingest the services, hosts, cloud assets, metrics, and SLOs that your Datadog has access to.

### The default automation rules for the Datadog plugin work as follows:

When you import your Datadog users and teams  into Rely.io you can either merge them into the teams that have previously been created by the Github plugin or you can create entirely new entities from the ones&#x20;

Similarly to teams and users they can either create new entities or be merged into previously existing ones, thus fleshing them out even further with the relevant information found in Datadog:

* Metrics
* SLOs
* Links to Documentation
* Links to observability dashboards
* The different environments the service is deployed to
* Etc.

By default, if you you have the appropriated labels in place cloud assets can automatically be merged to the and environments they’re supporting and are populated with relevant information found in Datadog:

* Cloud Provider
* Asset Type
* IaC tooling
* IaC code definition
* Links to observability dashboards