Key Concepts
This page describes core resources and the permission model used in Codeflow.
Repository
A repository is the basic unit for storing and managing source code and configuration files. Users can create repositories to manage code by project and record code change history through commits. Branches also let users separate and manage work such as feature development, testing, and deployment, providing a stable code management environment.
| Term | Description |
|---|---|
| Commit | A record of code changes applied to a repository. It includes information such as changes, author, and commit time. |
| Branch | A branch unit used to work on and manage code changes independently. It can be created from the latest commit of an existing branch or from a specific commit. |
| Default branch | The reference branch of a repository. When you create a repository in the console, the default is main, and workflow files are applied based on files in the default branch. |
| Tag | A reference point used to identify a version or deployment point based on a specific commit. Unlike branches, tags are used to mark specific commits rather than separate work streams. |
For how to create and manage repositories, branches, and tags, see Create and manage repositories, Create and manage branches, and Create and manage tags.
Pull request
A pull request (PR) is a collaboration feature for reviewing and merging code changes. Users can create a pull request from work done on a specific branch, share it with team members, and merge the code after review and approval. This helps maintain code quality and prevent errors that may occur during collaboration.
| Term | Description |
|---|---|
| Base branch | The target branch where pull request changes are finally merged. |
| Work branch | The branch that contains the changes to merge. |
| Reviewer | A user who reviews pull request changes and performs approval, rejection, or review cancellation. |
| Approval rule | Reviewer approval condition that must be met before a pull request can be merged. A repository can be configured with Single approval or All agreement. |
| Status | Indicates pull request progress. It is categorized as OPEN or CLOSED. |
| Approval status | Indicates the reviewer review result. It is categorized as Pending, Approved, Merged, Canceled, or Rejected. |
For how to create, review, and merge pull requests, see Create and manage pull requests.
Workflow
A workflow is a job definition unit for automatically running repetitive tasks such as builds and tests. Users can configure workflows based on events such as code changes or pull request creation to run tasks automatically. They can also check execution history through results, logs, and status information to determine success and respond quickly when errors occur. This reduces repetitive work in development and improves operational visibility.
| Term | Description |
|---|---|
| Workflow file | A YAML file that defines jobs to run. Store it in .yml or .yaml format under .codeflow/workflows in the default branch. |
| Workflow execution history | Records used to check workflow execution results and logs. Execution results are categorized as Succeeded, Failed, Running, Queued, or Canceled. |
| Runner | Execution environment that actually runs workflows. Codeflow supports self-hosted runner configurations. |
Repository-level settings required for workflow execution are managed in the Action settings tab of the console.
| Setting | Description |
|---|---|
| Repository token | Authentication key used to register a runner to a repository. |
| Repository variable | A setting that predefines values repeatedly used in workflows so they can be reused. |
For workflow file execution, log checks, and history management, see Manage workflows. For runner registration and repository variable management, see Action settings.
IAM-based role management
Codeflow follows role-based access control (RBAC) in IAM (Identity and Access Management). Codeflow resources are managed under projects, and access permissions are granted according to project roles and Codeflow service roles.
- Project Admins and Project Members can create, view, modify, and delete Codeflow resources in a project.
- Project Readers can view Codeflow resources in a project.
- To grant permissions only for Codeflow resources, use the Codeflow Manager or Codeflow Viewer service role. Codeflow Manager can create, view, modify, and delete all Codeflow resources. Codeflow Viewer can view all Codeflow resources.
- If you have only the Codeflow Manager role, you can create pull requests, but you cannot view the user list when assigning reviewers. To view the user list, you also need Project Member or IAM Project Admin permissions.
For the permission scope of project roles, see Project roles. For the permission scope of Codeflow service roles, see Service roles. For how to assign roles to users or groups, see Assign and modify roles.
| Permission | Project Admin | Project Member | Project Reader | Codeflow Manager | Codeflow Viewer |
|---|---|---|---|---|---|
| Manage project members | ✓ | ||||
| Create repositories | ✓ | ✓ | ✓ | ||
| Delete repositories | ✓ | ✓ | ✓ | ||
| Configure repositories | ✓ | ✓ | ✓ | ||
| View repositories | ✓ | ✓ | ✓ | ✓ | ✓ |
| Create pull requests | ✓ | ✓ | ✓ | ||
| View pull requests | ✓ | ✓ | ✓ | ✓ | ✓ |