Core Concepts
Projects
A Project in CodeCargo is the foundational container for your work. It represents a collection of GitHub repositories, Self-Service Workflows, a subset of your Service Catalog, workflow compliance scores, and more.
What Is a Project?
A Project is a logical container that links one or more GitHub repositories together, acting as a namespace for the applications, functional metadata, and automations that power them. You can use Projects to create representations of infrastructure, applications, microservices, or even to centralize core IT functions.
GitHub Integration
Each Project is connected to one or more GitHub repositories:
- The connection is read via CodeCargo’s GitHub App installation
- Repos must be accessible by the authenticated user
- Self-Service Workflows must live within these linked repositories
This mapping defines the scope of what your project can see and act upon.
Multi-Repository Projects
Link multiple repositories to a single project to support cross-repo workflows, microservice bundles, or create higher-level abstractions for your applications.
Working with Projects
Membership
CodeCargo users can access a project if they have access to at least one of the GitHub repositories assigned to the Project. Access to the underlying GitHub repository can be read or write. You can also grant explicit access to users and teams with specific roles (Admin, Editor, Viewer). See Access Control for full details on project roles, team management, and how GitHub permissions integrate with CodeCargo.
Self-Service Workflows
Projects are where you create and manage all your developer Self-Service Workflows.
Every Self-Service Workflow you create:
- Is saved under a specific project
- Has access to only the linked repositories
- Inherits context (permissions, branches, metadata) from the project’s repo links
Self-Service Workflows let users execute a GitHub Actions Reusable Workflow via the CodeCargo user interface, optionally providing parameters. As an example, you can create a Self-Service Workflow that deploys a Helm Chart. The user would be able to specify which Helm Chart they'd like to deploy.
Service Catalog
Every Project has a Service Catalog view - in particular, it is a view of the global Service Catalog with filters for components, owners, services, and pipelines defined by the repositories that make up the Project. The Service Catalog page has 3 specific panes:
- Split - hybrid view of the graph and table
- Graph - dedicated graph view
- Table - dedicated table view
This Service Catalog lets you identify relationships between all the components within every repository defined in this project. You can provide additional filters for components, owners, and type. For example, you can enter filters to show every single CI/CD pipeline owned by a particular user to help debug an issue.
Compliance Guardrails
CodeCargo can calculate compliance scores for each workflow defined in the GitHub repositories associated with your Project. Scores are represented as a number between 0% and 100%. You can manually run a compliance score by clicking on "Run Evaluation" next to the workflow. If you click on the workflow, you will see a comprehensive report that details which compliance guardrail rules the workflow passed and failed. This makes it easier for developers to implement fixes via the Expert Workflow Agent in the GenAI Editor.
In the future, CodeCargo will automatically fix non-compliant workflows and create PRs for your team to review. Compliance guardrail rules are configured in Workflow Compliance.
Project-Scoped Navigation
Projects act as first-class navigation containers. When you work within a project:
- Project-rooted breadcrumbs show your current location within the project context
- Project-scoped entity routes let you access workflows, repositories, and Building Blocks directly within the project scope (e.g.,
/projects/{projectId}/workflows/{workflowId}) - Scope preservation maintains your project context as you navigate between different views
Scope Switching
You can switch between projects while preserving your current view:
- Smart navigation takes you to the same page type in the target project when switching projects from a detail page
- Fallback handling automatically redirects to the appropriate list view when the specific entity doesn't exist in the target project
- Organization scope mapping allows you to exit project scope and view organization-wide equivalents of detail pages
- Default landing on project dashboards when selecting a project from anywhere in the interface
Context Preservation
When switching projects, CodeCargo attempts to maintain your current view. For example, if you're viewing a workflow detail page and switch projects, you'll land on the workflows list in the new project if that specific workflow doesn't exist there.
Project Administration
Projects are easy to manage:
| Action | Description |
|---|---|
| Create Project | Provide a name and link one or more GitHub repos |
| Edit Project | Update the name or repository links at any time |
| Delete Project | Deletes the project and all associated workflows |
| Access Control | Manage user and team access with project roles — see Access Control |
Repository Linking
Use a separate Project for each major team, business domain, or platform slice. It keeps things clean and scalable.
Example
Let’s say your team manages an application with source code spread across three repositories:
web-frontendapi-backendinfra-deployments
You could create a “Customer Platform” project and link all three repos. Inside, you could build Self-Service Workflows such as:
- Deploy staging frontend
- Rotate database credentials
- Trigger full stack smoke test
All of these workflows would live within the context of the Customer Platform project and run using GitHub Actions across the connected repos.