Skip to content

Repository map

The public group is displayed as Cloud Delivery Lab and retains the gabriel-canals-tfm namespace. It contains six projects; all exposed main as their default and protected branch in the public query on 26 October 2026.

Repository Responsibility Reviewed commit Files
cicd-templates Shared build, analysis and deployment templates. 642a84669137 3
terraform-modules Eight root modules, infrastructure pipeline and agent configuration. ae1502b0f4bd 69
web-application/apps/backend Java API, database configuration, Dockerfile and CI composition. 2c8e6ef861de 31
web-application/apps/frontend Java/FreeMarker/Vue interface, Dockerfile and CI composition. 1e56e856d4cf 183
web-application/deployments/backend Deployment, Service and ServiceAccount for the rest service. 82148d6303d0 3
web-application/deployments/frontend Web manifests and the AWS-specific Ingress. 38ef821c0b9d 4

File counts come from git ls-files at the listed commit. They include frontend static assets and do not measure complexity or test coverage.

Responsibility boundaries

Application repositories know how to build an image and which repository holds their manifests. They import three files from cicd-templates through include:project, currently at ref: main.

Deployment repositories hold the desired state of each service. They do not contain .gitlab-ci.yml in this snapshot. The pipeline that changes and applies their manifests still belongs to the application repository. No multi-project pipeline trigger or Argo CD/Flux reconciler is declared.

The infrastructure repository provisions networking, Kubernetes, databases and platform resources. It neither contains application source code nor applies the two application Deployments. This separation allows a normal application delivery without reprovisioning the infrastructure.

This documentation repository is a new addition. It compiles Markdown into HTML and publishes GitLab Pages; it does not access AWS, Google Cloud or infrastructure state.

Relationships

flowchart TD
  T["CI/CD templates"] --> A["Application repositories"]
  A --> R["Container Registry"]
  A --> D["Manifest repositories"]
  I["Infrastructure and agents"] --> K["EKS or GKE"]
  D --> J["Application deploy job"]
  J --> K
  R --> K

The arrow from manifests represents the application job reading them. Manifest projects do not execute that job themselves.

Existing traceability

Images are tagged with the full application SHA. The update job writes that reference into deployment.yaml and uses the same SHA as the deployment repository's commit message. Both image references in the snapshot match the reviewed application HEADs.

The templates' main reference can change between runs. Reconstructing a historical pipeline also requires its expanded configuration or the revisions of all templates; the application SHA alone does not pin those dependencies.

Cloning or renaming the group

When moving projects, review include:project, CD_PROJECT_PATH, agent contexts, ci_access authorizations, image references and remote state URLs. Changing the group's display name does not update these strings; changing its path requires a migration plan. Numeric project IDs and credentials must also be checked for their intended scope.

The root source-manifest.json file records the IDs, URLs and complete SHAs used for this edition. Sources explains how to refresh the review.

Sources and traceability