CodeCargo logo

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. The easiest way to think about it is a Project is a logical container for your applications, functional metadata, and automations that power them.

What Is a Project?

Projects are a logical container that links one or more GitHub repositories together. You can use Projects to create representations of infrastructure, applications, microservices, or even to centralize core IT functions.

Think of it as a namespace for developer automation and services.

Project Home

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 the a project if they have access to at least 1 of the GitHub repositories that are assigned to the Project. Access to the underlying GitHub repository can be read or write.

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:

  1. Split - hybrid view of the graph and table
  2. Graph - dedicated graph view
  3. Table - dedicated table view
Project Home

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 the Compliance Center.

<< Compliance Guardrails screenshot >>

Project Administration

Projects are easy to manage:

ActionDescription
Create ProjectProvide a name and link one or more GitHub repos
Edit ProjectUpdate the name or repository links at any time
Delete ProjectDeletes the project and all associated workflows
Access ControlTied to GitHub Roles and Permissions

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-frontend
  • api-backend
  • infra-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.

Previous
GenAI Editor