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: <workflow-name>
Version: v1
Triggers:
- Type: PUSH
Branches:
- main
Actions:
<action-name>:
# 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.
- 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.
- 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.
- The workflow file must exist in the branch specified in the
Branchesproperty for the workflow to run when a Push event occurs. - For example, if the workflow file is present only in the
mainbranch and not in thedevbranch, the workflow does not run even if a Push occurs in thedevbranch.
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:
<action-name>:
# 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:
- <previous-action>
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.
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.
- When using
DependsOn, be cautious to avoid creating cyclic dependencies within the workflow. - Example: if action
AsetsDependsOnto actionB, and actionBsetsDependsOnto actionA, 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:
<action-group-name>:
Actions:
<action-name-1>:
....
DependsOn:
- <action-name-2>
<action-name-2>:
....
DependsOn:
- <other-action-name>
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 |
- An action group can also set the
DependsOnproperty for external action groups or actions, just like a regular action. - However, actions inside an action group can only set
DependsOnfor other actions within the same group. - Actions outside the group cannot set
DependsOnfor actions inside the group.
- 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.
- Settings related to external resources are not checked during validation.
- Example: the
Config > Resource > ProjectNamesetting value of ancp/sourcebuild@v1.0.0action 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