Other_Kinds

Other Kinds

Template

A template in the T-matic platform defines the parameters showcased in the frontend part of the setup wizard and the sequences executed during the setup of the component.

Descriptor files for the "Template" kind might appear as follows:

apiVersion: backstage.io/v1beta2
kind: Template
# some metadata about the template itself
metadata:
  name: v1beta2-demo
  title: Test Action template
  description: scaffolder v1beta2 template demo
spec:
  owner: backstage/techdocs-core
  type: service

  # these are the steps which are rendered in the frontend with the form input
  parameters:
    - title: Fill in some steps
      required:
        - name
      properties:
        name:
          title: Name
          type: string
          description: Unique name of the component
          ui:autofocus: true
          ui:options:
            rows: 5
    - title: Choose a location
      required:
        - repoUrl
      properties:
        repoUrl:
          title: Repository Location
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts:
              - github.com

  # here's the steps that are executed in series in the scaffolder backend
  steps:
    - id: fetch-base
      name: Fetch Base
      action: fetch:template
      input:
        url: ./template
        values:
          name: '{{ parameters.name }}'

    - id: publish
      name: Publish
      action: publish:github
      input:
        allowedHosts: ['github.com']
        description: 'This is {{ parameters.name }}'
        repoUrl: '{{ parameters.repoUrl }}'

    - id: register
      name: Register
      action: catalog:register
      input:
        repoContentsUrl: {{ steps['publish'].output.repoContentsUrl }}
        catalogInfoPath: '/catalog-info.yaml'

Beyond the standard envelope, kind Template in the T-matic platform comprises the subsequent structure:

  • apiVersion and kind [required]: Values should strictly be backstage.io/v1beta2 and Template, in that order.

  • metadata.tags [optional]: A set of strings linked with the template, e.g., ['recommended', 'react']. These tags are also shown on the frontend, aiding users in searching and categorizing templates.

  • spec.type [required]: Indicates the component type generated by the template, e.g., 'website'. It aids in filtering templates and should ideally align with the Component spec.type constructed by the template.

  • spec.parameters [required]: Further details on the parameters key can be found here.

  • spec.steps [required]: Additional information on the steps key can be found here.

  • spec.owner [optional]: It points to the entity responsible for the template, e.g., 'artist-relations-team'. Within the T-matic platform, the owner of a Template is the main entity (usually a team) accountable for the Template. They're the primary contact for issues or feature requests. The core reason for this field is for display in the T-matic platform, offering users insight into the template's ownership. It's not intended for automated procedures, like runtime systems authorization. While many might work on the Template, there's always a sole owner.

kind
Default namespace
Generated relation type

Group (default), User

Identical to this entity, generally default

ownerOf, and its reverse, ownedBy.

Group

A group within the T-matic platform represents an organizational entity, which can take various forms such as a team, a business unit, or a community of individuals with shared interests and objectives. Members of these groups are modeled within the catalog using the kind User.

Here is an example of what descriptor files for this kind might look like:

apiVersion: backstage.io/v1alpha1
kind: Group
metadata:
  name: infrastructure
  description: The infra business unit
spec:
  type: business-unit
  profile:
    displayName: Infrastructure
    email: infrastructure@example.com
    picture: https://example.com/groups/bu-infrastructure.jpeg
  parent: ops
  children: [backstage, other]
  members: [jdoe]

Beyond the standard envelope, kind Group in the T-matic platform comprises the subsequent structure:

  • apiVersion and kind [required]: These fields remain exactly as "backstage.io/v1alpha1" and "Group," respectively.

  • spec.type [required]: This field defines the group's type, such as "team" or "business-unit." Organizations can choose the nomenclature that aligns with their organizational hierarchy.

  • spec.profile [optional]: This section allows for optional profile information about the group, primarily for display purposes. It can include details like a group email and a URL pointing to an image representative of the group.

  • spec.parent [optional]: Denotes the immediate parent group in the hierarchy, if applicable. Not all groups must have a parent, as the catalog supports multi-root hierarchies.

  • spec.children [required]: Specifies the immediate child groups of this group in the hierarchy, allowing for the organization of subgroups.

  • spec.members [optional]: Lists the users who are direct members of this group, enhancing user management and access control.

User

A user, within the T-matic platform, represents an individual, encompassing various roles such as an employee, contractor, or similar. Users are integral members of Group entities within the catalog, allowing for structured user management and collaboration.

Here's an example of how descriptor files for this kind might be structured:

apiVersion: backstage.io/v1alpha1
kind: User
metadata:
  name: jdoe
spec:
  profile:
    displayName: Jenny Doe
    email: jenny-doe@example.com
    picture: https://example.com/staff/jenny-with-party-hat.jpeg
  memberOf: [team-b, employees]

Beyond the standard envelope, kind User in the T-matic platform comprises the subsequent structure:

  • apiVersion and kind [required]: These fields remain exactly as "backstage.io/v1alpha1" and "User," respectively.

  • spec.profile [optional]: This section provides optional profile information about the user, primarily for display purposes. It can include details like a primary email address and a URL pointing to an image representing the user.

  • spec.memberOf [required]: Specifies the list of groups to which the user directly belongs. These memberships are not transitive and reflect the user's immediate group affiliations.

These user entries within the catalog play a crucial role in shaping the authentication mechanisms within the T-matic ecosystem. For a deeper discussion of these concepts, you can refer to the auth section of the documentation.

By defining users and their affiliations with groups, organizations can efficiently manage access control, permissions, and collaboration within the T-matic platform, ensuring seamless integration with authentication systems and user workflows.

Domain

A Domain within the T-matic platform serves as a unifying structure that groups together a collection of systems. These systems share commonalities such as terminology, domain models, business objectives, or documentation, effectively forming a bounded context.

Here's an example of what descriptor files for this kind might look like:

apiVersion: backstage.io/v1alpha1
kind: Domain
metadata:
  name: ecommerce
  description: Everything about ecommerce aspect of the organization's business
spec:
  owner: ecommerce-team

Beyond the standard envelope, kind Domain in the T-matic platform comprises the subsequent structure:

  • apiVersion and kind [required]: These fields remain exactly as "t-matic.io/v1" and "Domain," respectively.

  • spec.owner [required]: This field references an entity, such as a team (e.g., "tech-stack-team"), that serves as the ultimate owner of the domain. The owner holds responsibility for the domain's development and maintenance, making decisions, and serving as the primary point of contact for inquiries or feature requests related to the domain.

Location

A Location in the T-matic platform serves as a marker that points to other locations where asset inventory data can be found and accessed.

Here's an example of what descriptor files for this kind might look like:

apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: org-data
spec:
  type: url
  targets:
    - http://github.com/myorg/myproject/org-data-dump/catalog-info-staff.yaml
    - http://github.com/myorg/myproject/org-data-dump/catalog-info-consultants.yaml

Beyond the standard envelope, kind Location in the T-matic platform comprises the subsequent structure:

  • apiVersion and kind [required]: These fields remain exactly as "backstage.io/v1alpha1" and "Location," respectively.

  • spec [required]: The spec field is required, and at a minimum, it should contain an empty object.

  • spec.type [optional]: This field defines the location type, which is common to all the specified targets. If left out, it inherits the type from the location that originally read the entity data. This inheritance ensures that the referenced targets remain consistent, whether accessed locally from a file location or uploaded to a version control system (VCS).

  • spec.targets [optional]: Lists multiple targets as strings, each pointing to locations for catalog data. These targets can also be either absolute paths/URLs or relative paths, resolved relative to the Location entity's location.

PreviousKind ResourceNextassets-discovery

Last updated