Workspaces and projects
A workspace belongs to one personal or shared organization. The organization establishes ownership and namespace; the workspace establishes the operational boundary for delivery resources.
Workspaces
A workspace is the active isolation boundary for projects, pipelines, variables, secrets, DinaSync agents, and deployment targets.
The context switcher beside the Codinamo name displays the selected organization and workspace as Organization > Workspace.
Create a separate workspace when resources require a different team, environment, or access boundary. Changing the active workspace changes subsequent list and create operations.
Organization-level teams are not contained by a workspace. Assign a team a role on one or more workspaces to choose where it can operate.
Projects
A project groups delivery resources for one product or deployable unit:
-
overview metrics and recent activity;
-
optional hosted Git repository;
-
project pipelines;
-
project-scoped container Registry;
-
execution history reachable through its pipelines.
Project names participate in public repository and image paths and must be unique in the organization namespace.
Project tabs
- Overview
-
Shows pipeline, run, commit, and recent activity summaries below the stable project ID.
- Source
-
Shows the Repository section, its canonical
GIT-…ID, clone URL, status, and repository files when hosting is enabled. - Pipelines
-
Lists pipelines belonging to the project.
- Registry
-
Shows the canonical
REG-…ID and controls the project’s OCI repository, images, visibility, and credentials.
Access inheritance
The resource hierarchy is Organization > Workspace > Project. Pipelines, repositories, and registries belong to a project; runs belong to pipelines. A compatible role granted on a workspace can apply to current and future descendants.
See Organizations and namespaces for ownership and How access control works for scope inheritance.