Other Top-Level Properties

This document covers other top-level properties in your config.cap.yaml that provide special functionality.

Monorepo Support (monorepo)

If your GitLab project contains multiple applications (a "monorepo"), you need to tell CAP how to handle each application individually. The monorepo flag enables specific behaviors for this use case.

monorepo: true

What it Changes

Setting monorepo: true at the top level of your config.cap.yaml triggers the following automatic configurations:

1. Pipeline Context and Suffix:

   • The pipeline.context will automatically be set to your application's slug. This tells the GitLab pipeline to run jobs from the subdirectory containing your application.
   • The pipeline.suffix will also be set to your application's slug. This ensures that job names in the pipeline are unique (e.g., build:my-app-slug), preventing conflicts with other applications in the same monorepo.
   • You can still override these values manually in the pipeline block if needed.

2. Container Registry Path:

   • The path used to store your application's Docker images in the container registry will be modified to include the application's slug. For example, if your project's base registry path is registry.example.com/my-project, the images for an application with the slug api will be pushed to registry.example.com/my-project/api.

Example

Consider an application with the slug my-api in a monorepo.

config.cap.yaml:

monorepo: true
type: laravel
# ... other configs

Resulting Behavior:

• The pipeline will run as if you had set pipeline.context: "my-api" and pipeline.suffix: "my-api".
• When a Docker image is built, it will be tagged and pushed to a path like registry.example.com/your-project/my-api.