템플릿 작성

원문 보기 위키 갱신 2026.10.07

작은 yaml 정의로 나만의 템플릿을 만들 수 있습니다. 이 정의는 템플릿과 그 메타데이터, 템플릿에 필요한 몇 가지 입력 변수, 그리고 스캐폴딩 서비스가 실행하는 일련의 액션을 설명합니다.

출처: 문서

본문

간단한 예시를 살펴보겠습니다.

# Notice the v1beta3 versionapiVersion: scaffolder.backstage.io/v1beta3kind: Template# some metadata about the template itselfmetadata:  name: v1beta3-demo  title: Test Action template  description: scaffolder v1beta3 template demospec:  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        owner:          title: Owner          type: string          description: Owner of the component          ui:field: OwnerPicker          ui:options:            catalogFilter:              kind: Group    - 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: fetchBase      name: Fetch Base      action: fetch:template      input:        url: ./template        values:          name: ${{ parameters.name }}          owner: ${{ parameters.owner }}    - id: fetchDocs      name: Fetch Docs      action: fetch:plain      input:        targetPath: ./community        url: https://github.com/backstage/community/tree/main/backstage-community-sessions    - id: publish      name: Publish      action: publish:github      input:        description: This is ${{ parameters.name }}        repoUrl: ${{ parameters.repoUrl }}        defaultBranch: 'main'    - id: register      name: Register      action: catalog:register      input:        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}        catalogInfoPath: '/catalog-info.yaml'

자세히 파고들어 각 섹션이 무엇을 하는지, 무엇인지 뜯어보겠습니다.

`spec.parameters` - `FormStep | FormStep[]`

이 parameters는 프론트엔드에서 시퀀스로 수정할 수 있는 템플릿 변수입니다. 프론트엔드에 서로 다른 필드의 큰 목록 하나만 원한다면 단일 Step일 수 있고, 스캐폴더 플러그인 프론트엔드에서 다른 단계로 렌더링될 여러 단계로 나눌 수도 있습니다.

각 Step은 프론트엔드에서 어떻게 보일지 스타일링하기 위한 몇 가지 추가 요소가 있는 JSONSchema입니다. 이 단계들에 대해 우리는 이 라이브러리에 크게 의존합니다. 그것들은 훌륭한 문서와, 몇 가지 예시로 놀 수 있는 플레이그라운드를 가지고 있습니다.

그 라이브러리의 uiSchema라는 또 다른 옵션이 있는데, 우리는 그것을 활용해 라이브러리에 제공하는 기존 JSONSchema와 병합했습니다. 이것들이 단계 정의에서 볼 수 있는 작은 ui:* 속성들입니다.

예를 들어 플레이그라운드의 간단한 예시를 가져오면 다음과 같습니다.

// jsonSchema:{  "title": "A registration form",  "description": "A simple form example.",  "type": "object",  "required": [    "firstName",    "lastName"  ],  "properties": {    "firstName": {      "type": "string",      "title": "First name",      "default": "Chuck"    },    "lastName": {      "type": "string",      "title": "Last name"    },    "nicknames":{      "type": "array",      "items": {        "type": "string"      }    },    "telephone": {      "type": "string",      "title": "Telephone",      "minLength": 10    }  }}// uiSchema:{  "firstName": {    "ui:autofocus": true,    "ui:emptyValue": "",    "ui:autocomplete": "given-name"  },  "lastName": {    "ui:emptyValue": "",    "ui:autocomplete": "family-name"  },  "nicknames": {    "ui:options":{      "orderable": false    }  },  "telephone": {    "ui:options": {      "inputType": "tel"    }  }}

템플릿에서는 다음과 비슷할 것입니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: v1beta3-demo  title: Test Action template  description: scaffolder v1beta3 template demospec:  owner: backstage/techdocs-core  type: service  parameters:    - title: A registration form      description: A simple form example.      type: object      required:        - firstName        - lastName      properties:        firstName:          type: string          title: First name          default: Chuck          ui:autofocus: true          ui:emptyValue: ''          ui:autocomplete: given-name        lastName:          type: string          title: Last name          ui:emptyValue: ''          ui:autocomplete: family-name        nicknames:          type: array          items:            type: string          ui:options:            orderable: false        telephone:          type: string          title: Telephone          minLength: 10          ui:options:            inputType: tel

비밀(Secrets) 사용

무언가를 비밀로 표시하고 그 값이 보호되어 REST 엔드포인트를 통해 사용할 수 없도록 하고 싶을 수 있습니다. 내장 ui:field: Secret을 사용해 이렇게 할 수 있습니다.

이 속성을 일반 매개변수처럼 정의할 수 있지만, 이 매개변수의 소비는 ${{ parameters.myKey }}로는 사용할 수 없고, 대신 template.yaml에서 ${{ secrets.myKey }}를 사용해야 합니다.

매개변수는 검토 단계에서 자동으로 마스킹됩니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: v1beta3-demo  title: Test Action template  description: scaffolder v1beta3 template demospec:  owner: backstage/techdocs-core  type: service  parameters:    - title: Authentication      description: Provide authentication for the resource      required:        - username        - password      properties:        username:          type: string          # use the built in Secret field extension          ui:field: Secret        password:          type: string          ui:field: Secret  steps:    - id: setupAuthentication      action: auth:create      input:        # make sure to use ${{ secrets.parameterName }} to reference these values        username: ${{ secrets.username }}        password: ${{ secrets.password }}

템플릿의 each 단계 안에서도 비밀을 소비할 수 있습니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: v1beta3-demo  title: Test Action template  description: scaffolder v1beta3 template demospec:  owner: backstage/techdocs-core  type: service  parameters:    - title: Authentication      description: Provide authentication for the resource      required:        - service1        - token1        - service2        - token2      properties:        service1:          type: string        token1:          type: string          ui:field: Secret        service2:          type: string        token2:          type: string          ui:field: Secret  steps:    - id: setupAuthentication      action: auth:create      each:        [          {            name: '${{ parameters.service1 }}',            token: '${{ secrets.token1 }}',          },          {            name: '${{ parameters.service2 }}',            token: '${{ secrets.token2 }}',          },        ]      input:        name: ${{ each.value.name }}        token: ${{ each.value.token }}

비밀 스키마 정의

작업이 생성될 때 검증될 비밀에 대한 JSON 스키마를 정의할 수 있습니다. 이것은 비밀이 UI 폼이 아니라 프로그래밍 방식으로(예: CI/CD 파이프라인이나 API 호출을 통해) 전달될 때 유용합니다. 스키마는 작업 실행이 시작되기 전에 필수 비밀이 제공되도록 보장합니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: publish-to-npm  title: Publish to NPMspec:  owner: backstage/techdocs-core  type: service  # Define required secrets with a JSON Schema  secrets:    schema:      required:        - NPM_TOKEN      properties:        NPM_TOKEN:          type: string          description: NPM authentication token for publishing  parameters:    - title: Package Details      properties:        packageName:          type: string          title: Package Name  steps:    - id: publish      action: npm:publish      input:        packageName: ${{ parameters.packageName }}        token: ${{ secrets.NPM_TOKEN }}

필수 비밀 없이 작업이 생성되면, API는 설명적인 메시지와 함께 400 오류를 반환합니다.

{  "errors": [    {      "message": "secrets.NPM_TOKEN is required"    }  ]}

커스텀 단계 레이아웃

특정 단계에서 사용되는 폼의 기본 레이아웃이 필요에 맞지 않는다고 생각하면, 나만의 커스텀 단계 레이아웃을 제공할 수 있습니다.

기능 플래그에 따라 섹션 또는 필드 제거

기능 플래그에 따라 템플릿의 섹션 또는 필드만 숨길 수 있습니다. 이것은 프로덕션 환경에서 실험적 매개변수를 테스트하고 싶을 때 좋은 사용 사례입니다. 사용하려면 다음 템플릿을 살펴보세요.

spec:  type: website  owner: team-a  parameters:    - name: Enter some stuff      description: Enter some stuff      backstage:featureFlag: experimental-feature      properties:        inputString:          type: string          title: string input test        inputObject:          type: object          title: object input test          description: a little nested thing never hurt anyone right?          properties:            first:              type: string              title: first              backstage:featureFlag: nested-experimental-feature            second:              type: number              title: second

기능 플래그 experimental-feature가 활성화되어 있으면 첫 번째 매개변수 필드 집합이 표시됩니다. spec 안의 중첩 속성도 마찬가지입니다. 이 기능을 사용하고 싶다면 템플릿에서 backstage:featureFlag 키를 사용하세요.

기능 플래그는 spec.steps[].if(단계/액션을 실행할지 여부의 조건)에는 사용할 수 없습니다. 하지만 기능 플래그를 사용해 단계를 건너뛸 수 있는 매개변수를 표시할 수는 있습니다.

spec:  type: website  owner: team-a  parameters:    - name: Enter some stuff      description: Enter some stuff      backstage:featureFlag: experimental-feature      properties:        skipStep:          type: boolean          title: Whether or not to skip a step.          default: false        restOfParameters:          ...  steps:    - id: skipMe      name: A step to skip if the feature flag is turned on and the user selects true      action: debug:log      if: ${{ parameters.skipStep }}      input:        message: |        ...

저장소 선택기 (The Repository Picker)

저장소 제공자와 더 쉽게 작업하기 위해, string 필드의 uiSchema에서 ui:field 옵션을 재정의해 사용할 수 있는 커스텀 선택기를 만들었습니다. 텍스트 입력 블록 대신, 저장소 제공자를 쉽게 선택하고 프로젝트나 소유자, 저장소 이름을 입력할 수 있게 해 주는 우리가 만든 커스텀 컴포넌트를 렌더링합니다.

위의 전체 예시에서 그것을 볼 수 있으며, 별도의 단계이고 다음과 비슷합니다.

- title: Choose a location  required:    - repoUrl  properties:    repoUrl:      title: Repository Location      type: string      ui:field: RepoUrlPicker      ui:options:        allowedHosts:          - github.com

allowedHosts 부분은 이 템플릿이 게시하도록 활성화하려는 곳으로 설정해야 합니다. 그리고 app-config.yaml의 integrations config에 나열된 호스트라면 어떤 것이든 될 수 있습니다.

allowedHosts를 지정하는 것 외에도, allowedOwners 옵션을 설정해 템플릿이 특정 사용자/그룹/네임스페이스가 소유한 저장소에만 게시하도록 제한할 수 있습니다. allowedRepos 옵션으로 특정 저장소 이름 집합으로 더 좁힐 수 있습니다. 전체 예시는 다음과 같을 수 있습니다.

- title: Choose a location  required:    - repoUrl  properties:    repoUrl:      title: Repository Location      type: string      ui:field: RepoUrlPicker      ui:options:        allowedHosts:          - github.com        allowedOwners:          - backstage          - someGithubUser        allowedRepos:          - backstage

RepoUrlPicker의 가능한 모든 ui:options 입력 속성 목록은 여기를 방문하세요.

RepoUrlPicker는 plugin-scaffolder의 일부로 우리가 제공하는 커스텀 필드입니다. 나만의 커스텀 필드 확장을 작성해 나만의 커스텀 필드를 제공할 수 있습니다.

사용자의 `oauth` 토큰 사용

필드 입력으로 RepoUrlPicker를 사용할 때 즉시 얻을 수 있는 약간의 추가 마법이 있습니다. ui:options 아래에 몇 가지 추가 옵션을 제공해 RepoUrlPicker가 필요한 repository에 대해 사용자의 oauth 토큰을 가져오도록 할 수 있습니다.

이것은 새 저장소를 만들고 싶거나 기존 저장소에 연산을 수행하고 싶을 때 훌륭합니다.

이를 활용하는 샘플 템플릿은 다음과 같습니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: v1beta3-demo  title: Test Action template  description: scaffolder v1beta3 template demospec:  owner: backstage/techdocs-core  type: service  parameters:    ...    - title: Choose a location      required:        - repoUrl      properties:        repoUrl:          title: Repository Location          type: string          ui:field: RepoUrlPicker          ui:options:            # Here's the option you can pass to the RepoUrlPicker            requestUserCredentials:              secretsKey: USER_OAUTH_TOKEN              additionalScopes:                github:                  - workflow            allowedHosts:              - github.com    ...  steps:    ...    - id: publish      name: Publish      action: publish:github      input:        description: This is ${{ parameters.name }}        repoUrl: ${{ parameters.repoUrl }}        # here's where the secret can be used        token: ${{ secrets.USER_OAUTH_TOKEN }}    ...

위에서 RepoUrlPicker에 전달되는 추가 requestUserCredentials 객체가 있는 것을 볼 수 있습니다. 이 객체는 ${{ secrets.secretName }}으로 접근할 때 반환된 secret이 무엇으로 저장되어야 하는지 정의하며, 이 경우 USER_OAUTH_TOKEN입니다. 그리고 publish:github 액션에 token이라는 추가 input 필드가 있는 것을 볼 수 있으며, 그곳에서 다음과 같이 secret을 사용할 수 있습니다: token: ${{ secrets.USER_OAUTH_TOKEN }}.

사용자에게 oauth 토큰을 요청할 때 추가 범위를 전달할 수도 있는데, 템플릿을 여러 제공자에 게시할 수 있는 경우 제공자별로 할 수 있습니다.

이 기능을 작동시키려면 소스 코드 관리(SCM) 서비스에 대한 인증 제공자를 ScmAuthApi와 함께 구성해야 한다는 점에 주목하세요.

저장소 브랜치 선택기 (The Repository Branch Picker)

저장소 선택기와 유사하게, 자동 완성을 지원하는 브랜치 선택기가 있습니다. 전체 예시는 다음과 같을 수 있습니다.

- title: Choose a branch  required:    - repoBranch  properties:    repoBranch:      title: Repository Branch      type: string      ui:field: RepoBranchPicker      ui:options:        requestUserCredentials:          secretsKey: USER_OAUTH_TOKEN

자동 완성이 작동하려면 requestUserCredentials 객체를 전달하는 것이 필수입니다. 또한 저장소 선택기를 사용하고 있다면, 이 부분을 거기서 그대로 복제하면 됩니다. requestUserCredentials 객체에 대한 더 많은 정보는 The Repository Picker의 Using the Users oauth token 섹션을 참조하세요.

RepoBranchPicker의 가능한 모든 ui:options 입력 속성 목록은 여기를 방문하세요.

RepoBranchPicker는 plugin-scaffolder의 일부로 우리가 제공하는 커스텀 필드입니다. 나만의 커스텀 필드 확장을 작성해 나만의 커스텀 필드를 제공할 수 있습니다.

저장소 소유자 선택기 (The Repository Owner Picker)

저장소 선택기와 유사하게, 자동 완성을 지원하는 소유자 선택기가 있습니다. 전체 예시는 다음과 같을 수 있습니다.

- title: Choose an owner  required:    - repoOwner  properties:    repoOwner:      title: Repository Owner      type: string      ui:field: RepoOwnerPicker      ui:options:        host: github.com        excludedOwners:          - backstage        requestUserCredentials:          secretsKey: USER_OAUTH_TOKEN

자동 완성이 작동하려면 requestUserCredentials와 host 속성을 전달하는 것이 필수입니다. requestUserCredentials 객체에 대한 더 많은 정보는 The Repository Picker의 Using the Users oauth token 섹션을 참조하세요.

RepoOwnerPicker의 가능한 모든 ui:options 입력 속성 목록은 여기를 방문하세요.

RepoOwnerPicker는 plugin-scaffolder의 일부로 우리가 제공하는 커스텀 필드입니다. 나만의 커스텀 필드 확장을 작성해 나만의 커스텀 필드를 제공할 수 있습니다.

로그인한 사용자의 세부 정보 접근

템플릿을 작성할 때, 템플릿을 실행하는 사용자에 접근해 프로필이나 카탈로그의 사용자 Entity에서 세부 정보를 얻고 싶을 때가 있습니다.

로그인 제공자를 활성화하고 카탈로그의 사용자를 가리키는 로그인 리졸버가 있다면, ${{ user.entity }} 템플릿 표현식을 사용해 카탈로그의 원시 엔티티에 접근할 수 있습니다.

이것은 카탈로그에 User Entities의 spec.profile.email을 기록하는 프로세서를 설정해 그것을 참조하고 아래처럼 액션에 전달할 때 특히 유용할 수 있습니다.

steps:    action: publish:github    ...    input:        ...        gitAuthorName: ${{ user.entity.metadata.name }}        gitAuthorEmail: ${{ user.entity.spec.profile.email }}

또한 user.entity.metadata.annotations에도 접근할 수 있으므로, 거기에 저장된 추가 정보가 있다면 그것도 참조할 수 있습니다.

소유자 선택기 (The Owner Picker)

스캐폴더가 카탈로그에 새 컴포넌트를 추가해야 할 때, 그것에 대한 소유자가 필요합니다. 이상적으로 사용자는 스캐폴더 폼을 거칠 때 Backstage가 이미 알고 있는 사용자와 그룹에서 소유자를 선택할 수 있어야 합니다. OwnerPicker는 이미 카탈로그에 있는 그룹 및/또는 사용자의 검색 가능한 목록을 생성해 소유자를 선택하게 하는 커스텀 필드입니다. 두 종류 중 어떤 것(또는 둘 다)이 나열될지 catalogFilter.kind 옵션에서 지정할 수 있습니다.

owner:  title: Owner  type: string  description: Owner of the component  ui:field: OwnerPicker  ui:options:    catalogFilter:      kind: [Group, User]

OwnerPicker의 가능한 모든 ui:options 입력 속성 목록은 여기를 방문하세요.

`catalogFilter`

catalogFilter는 카탈로그 api 필터를 사용해 엔티티 목록을 필터링할 수 있게 해 줍니다.

예를 들어 default 네임스페이스의 사용자와 github.com/team-slug 어노테이션이 있는 그룹을 보여주고 싶다면, 다음과 같이 할 수 있습니다.

catalogFilter:  - kind: [User]    metadata.namespace: default  - kind: [Group]    metadata.annotations.github.com/team-slug: { exists: true }

커스텀 검증 메시지

ajv-errors 플러그인 라이브러리가 ajv에 지원하는 것처럼 커스텀 JSON 스키마 검증 메시지를 지정할 수 있습니다.

`spec.steps` - `Action[]`

steps는 이 템플릿의 일부로 일어나길 원하는 것들의 배열입니다. 그것들은 같은 표준 형식을 따릅니다.

- id: fetchBase # A unique id for the step  name: Fetch Base # A title displayed in the frontend  if: ${{ parameters.name }} # Optional condition, skip the step if not truthy  each: ${{ parameters.iterable }} # Optional iterable, run the same step multiple times  action: fetch:template # An action to call  input: # Input that is passed as arguments to the action handler    url: ./template    values:      name: ${{ parameters.name }}

액션 ID 명명

커스텀 액션을 사용할 때, 템플릿 표현식 문제를 피하기 위해 액션 ID에 camelCase를 사용하세요. 대시가 있는 액션 ID는 ${{ steps.my-action.output.value }} 같은 표현식이 기대한 값 대신 NaN을 반환하게 합니다. my-action 대신 myAction을 사용하거나, 대괄호 표기법으로 출력에 접근하세요: ${{ steps['my-action'].output.value }}.

기본적으로 우리는 살펴볼 수 있는 몇 가지 내장 액션을 제공하며, 나만의 커스텀 액션을 만들 수도 있습니다.

each 값은 배열 또는 객체로 해석되어야 합니다. 현재 반복 값은 ${{ each }} 입력에서 사용할 수 있습니다.

예시:

each: ['apples', 'oranges']input:  values:    fruit: ${{ each.value }}

each: [{ name: 'apple', count: 3 }, { name: 'orange', count: 1 }]input:  values:    fruit: ${{ each.value.name }}    count: ${{ each.value.count }}

each가 사용될 때, 반복된 단계의 출력은 각 반복의 출력 배열로 반환됩니다.

상태 확인 함수 - `always()`와 `failure()`

기본적으로 스캐폴더 실행 중 단계가 실패하면, 이후의 모든 단계는 건너뛰고 작업은 실패로 표시됩니다. 템플릿이 이후 단계가 실패할 때 정리해야 하는 외부 리소스(저장소, 클라우드 인프라, 배포)를 생성할 때는 이것이 문제가 될 수 있습니다.

상태 확인 함수는 실패 후에도 실행할 단계를 제어할 수 있게 해 줍니다. 단계의 if 필드의 ${{ ... }} 템플릿 표현식 안에서 그것들을 사용합니다.

	Function	Description
`always()`	이전 단계가 통과했든 실패했든 항상 단계를 실행합니다.
`failure()`	이전 단계가 실패했을 때만 단계를 실행합니다.

이 함수들은 ${{ always() }} 또는 ${{ failure() }} 같은 템플릿 표현식으로 사용되어야 합니다.

단계가 실패한 후, 스캐폴더는 if 표현식이 이 상태 확인 함수 중 하나를 호출하는 이후 단계만 시도합니다.

사용법

steps:  - id: cleanup    name: Cleanup Resources    action: my:cleanup:action    if: ${{ always() }}

예시: 실패 시 정리

일반적인 패턴은 초기 단계에서 리소스를 만들고, 무언가 잘못되었을 때만 실행되는 정리 단계를 추가하는 것입니다.

steps:  - id: create-repo    name: Create Repository    action: publish:github    input:      repoUrl: ${{ parameters.repoUrl }}  - id: deploy    name: Deploy to Kubernetes    action: deploy:kubernetes    input:      manifest: ./k8s/deployment.yaml  # Only runs when a previous step failed — cleans up the repository  - id: cleanup-repo    name: Delete Repository    action: github:repo:delete    if: ${{ failure() }}    input:      repoUrl: ${{ parameters.repoUrl }}  # Always runs — post an audit event regardless of outcome  - id: audit    name: Post Audit Event    action: debug:log    if: ${{ always() }}    input:      message: 'Scaffolder run completed for ${{ parameters.repoUrl }}'  # Does not run after a failure, because it does not invoke a status check function  - id: plain-truthy-condition    name: Plain Truthy Condition    action: debug:log    if: ${{ true }}    input:      message: 'This step is skipped after a previous failure'

출력 (Outputs)

각 개별 단계는 작업이 끝난 후 스캐폴더 프론트엔드에서 사용할 수 있는 일부 변수를 출력할 수 있습니다. 이것은 백엔드로 생성된 엔티티에 연결하거나, 생성된 저장소에 연결하거나, 마크다운 텍스트 블록을 보여주는 것 같은 것에 유용합니다.

output:  links:    - title: Repository      url: ${{ steps['publish'].output.remoteUrl }} # link to the remote repository    - title: Open in catalog      icon: catalog      entityRef: ${{ steps['register'].output.entityRef }} # link to the entity that has been ingested to the catalog  text:    - title: More information      content: |        **Entity URL:** `${{ steps['publish'].output.remoteUrl }}`

출력 links와 text 항목은 단계 조건과 같은 구문을 사용하는 선택적 if 조건을 지원합니다. 조건이 false로 평가되는 항목은 출력에서 제외됩니다.

output:  links:    - title: Repository      url: ${{ steps['publish'].output.remoteUrl }}    - if: ${{ parameters.enableCI === "Yes" }}      title: CI Dashboard      url: https://ci.example.com/${{ parameters.name }}  text:    - title: Summary      content: |        **Component:** `${{ parameters.name }}`    - if: ${{ parameters.showDetails }}      title: Details      content: |        **CI enabled:** ${{ parameters.enableCI }}

템플릿 구문

예시에서 ${{ }}로 감싼 표현식을 보셨을 것입니다. 이것들은 템플릿의 서로 다른 부분을 연결하고 붙이는 템플릿 문자열입니다. parameters 섹션의 모든 폼 입력은 이 템플릿 구문을 사용해 사용할 수 있습니다(예: ${{ parameters.firstName }}은 parameters의 firstName 값을 삽입합니다). 이것은 폼의 값을 다른 단계로 전달하고 이 입력 변수를 재사용하는 데 훌륭합니다. 이 템플릿 문자열은 매개변수의 타입을 보존합니다.

${{ parameters.firstName }} 패턴은 템플릿 파일에서만 작동합니다. 코드에서 UI가 제공한 값을 사용하기 시작하려면 ${{ values.firstName }} 패턴을 사용해야 합니다. 또한 UI의 매개변수를 fetch:template 단계의 입력으로 전달해야 합니다.

apiVersion: scaffolder.backstage.io/v1beta3kind: Templatemetadata:  name: v1beta3-demo  title: Test Action  description: scaffolder v1beta3 template demospec:  owner: backstage/techdocs-core  type: service  parameters:    - title: Fill in some steps      required:        - name      properties:        name:          title: Name          type: string          description: Unique name of your project        urlParameter:          title: URL endpoint          type: string          description: URL endpoint at which the component can be reached          default: 'https://www.example.com'        enabledDB:          title: Enable Database          type: boolean          default: false  ...  steps:    - id: fetchBase      name: Fetch Base      action: fetch:template      input:        url: ./template        values:          name: ${{ parameters.name }}          url: ${{ parameters.urlParameter }}          enabledDB: ${{ parameters.enabledDB }}

그런 다음 내장 템플릿 액션을 사용한다면, 코드에서 변수를 사용하기 시작할 수 있습니다. Nunjitsu가 지원하는 템플릿 태그와 함수를 사용할 수도 있습니다. Nunjucks 문서의 구문을 사용하기 전에 Nunjitsu 호환성 가이드를 확인하세요.

#!/bin/bashecho "Hi my name is ${{ values.name }}, and you can fine me at ${{ values.url }}!"{% if values.enabledDB %}echo "You have enabled your database!"{% endif %}

위의 Outputs 섹션에서 볼 수 있듯, actions와 steps도 무언가를 출력할 수 있습니다. steps.$stepId.output.$property를 사용해 그 출력을 가져올 수 있습니다.

액션에 정의된 모든 inputs와 outputs에 대해 더 읽으려면 JSONSchema의 코드 부분을 읽거나, 내장 액션에 대해 더 읽을 수 있습니다.

표현식에 대해 더 자세히

템플릿의 ${{ }} 구조는 Nunjucks 구문의 집중된 하위 집합을 지원하는 Nunjitsu 템플릿 엔진으로 평가됩니다. 일반 구문 참조로는 Nunjucks 템플릿 문서를 사용하고, 지원되는 기능에 대해서는 Nunjitsu 호환성 가이드를 확인하세요.

Backstage의 내장 템플릿 확장과 나만의 커스터마이즈를 만드는 방법에 대한 정보는 Templating Extensions에서 찾을 수 있습니다.

템플릿 편집기 (Template Editor)

템플릿 작성은 대부분의 경우 반복적인 과정입니다. 템플릿이 좋은 사용자 경험을 가지고 기대대로 작동하는지 확인하기 위해 템플릿을 테스트해야 합니다. 이 과정을 돕기 위해 스캐폴더에는 데이터를 쿼리할 수 있는 실제 환경에서 템플릿을 테스트하고, 드라이 런 모드로 액션을 실행해 그 결과를 볼 수 있게 해 주는 내장 템플릿 편집기가 있습니다.

템플릿 편집기에 접근하려면 템플릿 페이지로 가서 컨텍스트 메뉴에서 "Template Editor"를 선택하거나 {scaffolder-path}/edit URL로 이동하세요. (즉 기본 라우트는 /create/edit입니다.)

템플릿 편집기에는 3개의 주요 섹션이 있습니다.

원격 템플릿 디렉터리 로드(Load Template Directory): 로컬 템플릿 디렉터리를 로드해 나만의 템플릿을 편집하고 실행을 시도할 수 있게 해 줍니다.
템플릿 폼 편집(Edit Template Form): 샘플 템플릿을 사용하거나 카탈로그에서 템플릿을 로드해 템플릿 폼을 미리 보고 편집합니다.
커스텀 필드 탐색기(Custom Field Explorer): 설치된 사용 가능한 커스텀 필드 확장을 보고 놀 수 있습니다.

원격 템플릿 디렉터리 로드

템플릿을 포함한 로컬 파일 시스템의 디렉터리를 로드하고, 폼을 미리 보면서 그 안의 파일을 편집하며 템플릿을 실행할 수 있게 해 줍니다.

오른쪽의 폼을 완성하고 Create 버튼을 클릭하면, 템플릿이 드라이 런 모드로 실행되고 결과가 화면 하단에 팝업될 Dry-run result 드로어에 표시됩니다.

여기에서 템플릿 실행의 모든 파일 시스템 결과뿐 아니라 실행된 각 액션의 로그도 찾을 수 있습니다.

템플릿 폼 편집

이것은 템플릿 편집기의 축소 버전으로, 카탈로그에서 어떤 템플릿이든 선택하고 사용자에게 제시된 폼에 몇 가지 수정을 해 변경을 테스트할 수 있게 해 줍니다.

이 폼의 변경은 템플릿에 저장되지 않으며, 변경을 테스트한 후 템플릿 파일에 수동으로 복제하기 위한 것임을 명심하세요.

커스텀 필드 탐색기

커스텀 필드 탐색기는 backstage 인스턴스에 로드된 어떤 커스텀 필드든 선택하고 다른 값과 구성을 테스트할 수 있게 해 줍니다.

프레젠테이션 (Presentation)

소프트웨어 템플릿의 spec.presentation 필드를 사용해 "Back", "Review", "Create" 버튼의 텍스트를 구성할 수 있습니다. 무언가를 "만들지" 않고 "갱신"하는 템플릿을 원할 수도 있습니다. 이 기능으로 필요에 따라 변경할 수 있습니다. 사용 방법의 예는 다음과 같습니다.

---spec:  owner: scaffolder/maintainers  type: website  presentation:    buttonLabels:      backButtonText: 'Return'      createButtonText: 'Update'      reviewButtonText: 'Verify'