R
Rich Rein
Specific to our use case, we would love to be able to do the following kinds of examples (similar to what is available in the GitHub integration today):
* The ability to ingest YML/JSON files and parse the content (e.g., to map dependencies and their associated versions from a given repository's package.json).
* While it is not a Azure Devops convention like it is in GitHub, I could imagine a use case where we follow the CODEOWNERS convention to designate owners (for ingestion into Port, as a means for designating the relationship between a given repository and its owner - because ADO repos roll up to projects, but not to ADO teams). Similarly, we could come up with other file conventions for allowing an individual repository owner to help designate other useful pieces (similar to the "tag a Github repositor with the associated SonarQube project name - except that ADO does not have a facility for tagging/metadata at the repository level, so we need another way to work around being able to capture repository level information).
* We have a repository that is a library of UI components. This repository currently includes a JSON file as a part of the build process that specifies the available components (and some associated metadata). In order to create a catalog of available UI components for display within Port, it would be nice to use that file as a datasource.
Matan Grady
Rich Rein thank you for all these useful examples! the use case is quite clear. I liked the UI library example, it's an interesting use case!
If you're using storybook (or alternative), it would be nice to see these components in Port as well as a link (or even iFrame) of their storybook.
The file kind feature is relatively new for our other Git providers, we will gather interest for ADO and hopefully will get there too!
R
Rich Rein
Matan Grady We are currently using styleguidist (as you mentioned, an alternative to Storybook - though reevaluating Storybook is on our backlog). In our portal POC, we actually did exactly as you described - using an iframe to pull in the example for a given component, with a link to open the full examples in a new tab. In order to complete the POC, we simply hardcoded the components that were available...but looking forward to being able to create them dynamically from the JSON-based list (and thus minimizing maintenance/manual effort when a component is added or removed)!
Matan Grady
Rich Rein thank you for the additional context! appreciate it