Implement Support for Dynamic File Path in Port Import
L
Leo Sivak
Current Behavior:
The file kind type currently does not support dynamic file paths for importing file content into a port.
This limitation restricts flexibility when dealing with multiple files or varying file locations.
Proposed Change:
Enhance the file kind type to support dynamic file paths, similar to the functionality already implemented in port YAML.
This change will allow each document processed as file-kind mapping to specify a different file path, providing greater flexibility in file content import.
example importing swagger spec in git-ops fashion:
interfaces:
- name: Petstore
openApiSpec: file://petstore.yaml
- name: Data Set API (DSAPI)
openApiSpec: file://../dsapi/uspto.yaml
The expectation from mapping this file would be to create two interface entities which have a swagger tab containing the specified OAS files.
Stewart Southern
Leo Sivak asked me to add some more details of what we're trying to achieve here.
We are developing an internal yaml based workload specification format, similar to score.dev. One of the use cases for this is so that Port can ingest the yaml files from our GitLab data sources. We do this by using a file kind mapping with a selector.files.path property that searches the entire repository for yaml workload specification files and then mapping the contents of that file to an entity type "interface".
One of the properties of the "interface" entity which we would like to map is the schema for that interface. Currently we support Open API Spec schemas and Avro schemas for Kafka messages. We don't want to force developer teams to store all their schema files in a specific location or to duplicate the contents of the schema file into the workload specification yaml, so we intend to support referencing files elsewhere in the repository using the same format Port does in the port.yml files, as found in https://docs.port.io/build-your-software-catalog/sync-data-to-catalog/git/azure-devops/gitops/#ingesting-project-file-contents
The behaviour we desire is that if a file kind mapping is occurring and the property being mapped is of a type which support ingesting project file contents in port.yml and the value found indicates that it is a file using the file://myfile format then the contents of myfile are placed in the entity property.
A full worked example is below.
Workload specification file:
interfaces:
- id: petstore-interface
specification:
oasFile: file://../interfaces/petstore.oas.yaml
Data source mapping:
createMissingRelatedEntities: true
deleteDependentEntities: true
enableMergeEntity: true
resources:
- kind: file
port:
entity:
mappings:
blueprint: '"interface"'
identifier: .item.value.id
properties:
oasSpec: .item.specification.oasFile
itemsToParse: >-
.file.content | if has("interfaces") then .interfaces |
to_entries else empty end
selector:
files:
path: '**/workloads/interfaces.yaml'
query: 'true'
Yields an entity with id "petstore-interface" and a property containing the contents of "petstore.oas.yaml" which can be rendered using the swagger UI functionality already existent within Port.
Let me know if this is sufficiently clear, or where things aren't clear.