--- title: "Workflow format - YAML" slug: "sourceband-workflow-use-format" updated: 2026-09-17T09:18:20Z published: 2026-09-17T09:18:20Z canonical: "guide.ncloud-docs.com/sourceband-workflow-use-format" stale: true --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # Workflow format - YAML Available in VPC Workflow files must be written in a predefined format to be recognized as valid and executable. This section explains the YAML format required for defining a workflow and the meaning of each property. ## Basic structure of workflow ``` Name: Version: v1 Triggers: - Type: PUSH Branches: - main Actions: : # Identifies the action. Do not modify this value. Identifier: ncp/sourcebuild@v1.0.0 # Defines the action's properties. Config: .... ``` | Property name | Description | Required | | --- | --- | --- | | Name | Workflow name | O | | Version | Workflow schema version | O | | Triggers | Workflow trigger setting | X | | Actions | Workflow action definition | O | ### Workflow name You can specify the name of the workflow. The name must meet the following conditions: - Must be at least 1 character. - Must be less than 100 characters. - Only uppercase and lowercase letters (A to Z and a to z), numbers (0 to 9), hyphens (-), and underscores (_) are allowed. Caution - The workflow name appears in the workflow list within the console, and it is not related to the file name used for storage. ### Workflow schema version You can explicitly specify the version of the workflow schema. Note - The currently supported workflow schema version is `v1`. ### Workflow trigger setting A workflow trigger defines when the workflow should automatically run in response to a specific event. Triggers are defined in a list format, and multiple triggers can be set in parallel. Currently, only the `PUSH` trigger is supported. Other types such as `PR` and `SCHEDULE` will be added in the future. Trigger configuration must follow the following format: | Property name | Description | Required | | --- | --- | --- | | Type | Event type (for example, PUSH, PR, or SCHEDULE) | O | | Branches | List of branches to monitor for the event (only applicable when the event type is PUSH) | X | #### Push trigger (type: PUSH) Push trigger is configured to run the workflow when a Push event occurs in the repository. ``` Triggers: - Type: PUSH Branches: - main - dev ``` In the example above, the workflow runs if a Push event occurs in the `main` or `dev` branch. Caution - The workflow file must exist in the branch specified in the `Branches` property for the workflow to run when a Push event occurs. - For example, if the workflow file is present only in the `main` branch and not in the `dev` branch, the workflow does not run even if a Push occurs in the `dev` branch. To detect Push events in all branches without restriction, you may omit the `Branches` property. ``` Triggers: - Type: PUSH ``` ## Basic structure of workflow action An "action" refers to a unit of task that is actually executed within a workflow. The `Actions` property is required, which defines one or more actions. Actions are executed in a defined order or based on specified conditions, performing various tasks such as building or deploying resources depending on how the actions are defined. ``` Actions: : # Identifies the action. Do not modify this value. Identifier: ncp/sourcebuild@v1.0.0 # Defines the action's properties. Config: # Specifies the resource you want to use Resource: ... DependsOn: - ``` Action names are used as keys of the `Actions` sub-object, and they must be unique. Each action has the following properties: | Property name | Description | Required | | --- | --- | --- | | Identifier | A unique identifier for the action to be executed. Specify it in the "action-name@version" format. | O | | Config | Contains detailed configuration items for the specified action. The configuration items vary depending on the action type. | O | | DependsOn | If another action must run first, define the dependency explicitly. | X | ### Identifier `Identifier` is a unique identifier used to specify the action to execute. If the identifier format is incorrect, validation may fail. Example: `ncp/sourcebuild@v1.0.0` ### Config `Config` is the section where you define the configuration values for running each action. Since the format of this property depends on the action's identifier, you must check the appropriate format for each action. For detailed config formatting, see [Workflow action list](/docs/en/sourceband-workflow-use-actions). ### DependsOn `DependsOn` is the property used to specify an action that must be completed before the current one runs. You can define it by listing action or action group names, which is useful when actions need to run in sequence. Caution - When using `DependsOn`, be cautious to avoid creating cyclic dependencies within the workflow. - Example: if action `A` sets `DependsOn` to action `B`, and action `B` sets `DependsOn` to action `A`, this creates a cyclic dependency, resulting in an invalid workflow. ### Action group feature You can group multiple actions into a single group to configure a logical unit. ``` Actions: : Actions: : .... DependsOn: - : .... DependsOn: - ``` When the Actions property is added under an action name, that section is treated as an action group. Description of the properties under an action group are as follows: | Property name | Description | Required | | --- | --- | --- | | Actions | Defines the actions included in the action group. | O | | DependsOn | Defines dependency relationships between actions. | X | Note - An action group can also set the `DependsOn` property for external action groups or actions, just like a regular action. - However, actions inside an action group can only set `DependsOn` for other actions within the same group. - Actions outside the group cannot set `DependsOn` for actions inside the group. Caution - You cannot define an action group within another action group. - Action group configuration is not supported in the Visual Editor and must be set up using YAML. ## Workflow validation A workflow file is considered valid only if it meets the following conditions: - No YAML syntax errors. - Follows the schema without missing required properties. - No duplicate action names or group names. - Does not reference undefined names in `DependsOn`. If these conditions are not met, the workflow is classified as `invalid` and cannot be executed. Caution - Settings related to external resources are not checked during validation. - Example: the `Config > Resource > ProjectName` setting value of a `ncp/sourcebuild@v1.0.0` action is not verified during validation. Whether the resource exists can only be confirmed indirectly if the action fails during workflow execution. ### Full example ``` Name: example-workflow Version: v1 Triggers: - Type: PUSH Branches: - main Actions: build: Identifier: ncp/sourcebuild@v1.0.0 Config: Resource: ProjectName: example deploy: Identifier: ncp/sourcedeploy-server@v1.0.0 Config: Resource: ProjectName: example StageName: example-stage ScenarioName: example-scenario DependsOn: - build ```