GitOps
Port's GitHub integration makes it possible to manage Port entities with a GitOps approach, making your code repositories the source of truth for the various infrastructure assets you want to manage.
💡 GitHub GitOps common use cases​
- Use GitHub as the source-of-truth for your microservices, packages, libraries and other software catalog assets.
- Allow developers to keep the catalog up-to-date, by making updates to files in their Git repositories.
- Create a standardized way to document software catalog assets in your organization.
Managing entities using GitOps​
To manage entities using GitOps, you will need to add a port.yml
file to the default branch (usually main
) of your repository.
Note that the port.yml
file is not the same as the port-app-config.yml
file used to configure the GitHub integration, and does not replace it.
The port.yml
file can specify one or more Port entities that will be ingested to Port, and any change made to the port.yml
file will also be reflected inside Port.
To manage entities using GitOps and the port.yml
file, Port's Github app must be installed, as it listens to push
events sent from Github.
This means that if the port.yml
file exists in the repository before installing the app, it will not be picked up automatically. You will need to make some update to the port.yml
file and push it to the repository in order for the Git app to properly track and ingest the entity information.
GitOps port.yml
file​
The port.yml
file is how you specify your Port entities that are managed using GitOps and whose data is ingested from your Git repositories.
Here are examples for valid port.yml
files:
- Single entity
- Multiple entities
identifier: myEntity
title: My Entity
blueprint: myBlueprint
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
relations:
mySingleRelation: myTargetEntity
myManyRelation:
- myTargetEntity1
- myTargetEntity2
- identifier: myEntity1
title: My Entity1
blueprint: myFirstBlueprint
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
relations:
mySingleRelation: myTargetEntity
myManyRelation:
- myTargetEntity1
- myTargetEntity2
- identifier: myEntity
title: My Entity2
blueprint: mySecondBlueprint
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
Since both of the valid port.yml
formats follow the same structure, the following section will explain the format based on the single entity example.
port.yml
structure​
Here is an example port.yml
file:
identifier: myEntity
title: My Entity
blueprint: myBlueprint
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
relations:
mySingleRelation: myTargetEntity
myManyRelation:
- myTargetEntity1
- myTargetEntity2
- The
identifier
key is used to specify the identifier of the entity that the app will create and keep up-to-date when changes occur:
identifier: myEntity
title: My Entity
...
- The
title
key is used to specify the title of the entity:
identifier: myEntity
title: My Entity
...
- The
blueprint
key is used to specify the identifier of the blueprint to create this entity from:
...
title: My Entity
blueprint: myBlueprint
...
- The
properties
key is used to map the values to the different properties of the entity:
...
title: My Entity
blueprint: myBlueprint
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
...
- The
relations
key is used to map target entities to the different relations of the entity:
- Single relation
- Many relation
...
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
relations:
mySingleRelation: myTargetEntity
...
properties:
myStringProp: myValue
myNumberProp: 5
myUrlProp: https://example.com
relations:
myManyRelation:
- myTargetEntity1
- myTargetEntity2
Ingesting repository file contents​
It is possible to use the contents of files in the repository as the value for entity properties using a simple reference.
The following example will read the string contents of ~/module1/README.md
and upload it to myStringProp
of the specified entity.
Repository folder structure used for the example:
root
|
+- port.yml
|
+-+ module1
| |
| +- README.md
| |
| +-+ src
...
port.yml
file:
blueprint: code_module
title: Module 1
identifier: module_1_entity
properties:
myStringProp: file://module1/README.md
Using relative paths​
It is also possible to use paths relative to the location of the port.yml
spec file.
For example: file://./
is used to reference a file in the same directory as the port.yml
file. file://../
is used to reference a file that is one directory above and so on.
The following example reads README.md
and module1/requirements.txt
using paths relative to port.yml
Repository folder structure used for the example:
root
|
+-+ meta
| |
| +-- port.yml
| |
| +-+ README.md
|
+-+ module1
| |
| +- requirements.txt
| |
| +-+ src
...
port.yml
file:
blueprint: code_module
title: Module 1
identifier: module_1_entity
properties:
readme: file://./README.md
module1Requirements: file://../module1/requirements.txt
Examples​
Check out the example repository for a microservice blueprint and a matching port.yml
file which specifies a microservice entity.
Advanced​
Refer to the advanced page for advanced use cases and configurations.