feat: sprint 83 — Import Compose: wizard 3 passos para importar docker-compose.yml de Git Repository público

Programado em par com: Claude IA

Author: joseafilho

.scratch/sprint-83/issues/01-compose-parser.md

@@ -0,0 +1,17 @@
+---
+title: Parser de docker-compose.yml a partir de Git Repository
+status: open
+sprint: 83
+---
+
+O GreenCap precisa buscar e interpretar um `docker-compose.yml` a partir de uma URL de Git Repository público. O resultado do parse deve ser um modelo intermediário que represente os serviços, portas, variáveis de ambiente, volumes e instruções de build encontrados no arquivo, sem nenhum acoplamento à UI ou à camada Kubernetes.
+
+O parser recebe a URL do repositório Git, o branch e o path opcional para o arquivo dentro do repositório (padrão: `docker-compose.yml` na raiz). O clone é feito de forma efêmera, apenas para leitura do arquivo.
+
+A tradução de `environment:` segue a heurística de chave sensível: chaves contendo `PASSWORD`, `SECRET`, `TOKEN`, `KEY` ou `CREDENTIAL` (case-insensitive) são classificadas como sensíveis; as demais como não sensíveis.
+
+Volumes do tipo named (sem prefixo `./` ou `/`) são classificados como candidatos a PVC. Volumes do tipo bind-mount são classificados como ignorados.
+
+Diretivas não reconhecidas ou não suportadas (como `networks:`, `restart:`, `healthcheck:`, `deploy:`, `profiles:`, `logging:`, `ulimits:`) são coletadas em uma lista separada para exibição de aviso na tela de revisão.
+
+O modelo intermediário resultante deve ser suficientemente completo para que a camada de revisão da UI possa renderizá-lo e permitir edição dos campos configuráveis (tamanho de PVC, StorageClass, nome de imagem para serviços com `build:`) antes de qualquer chamada ao cluster.

.scratch/sprint-83/issues/02-import-compose-service.md

@@ -0,0 +1,17 @@
+---
+title: ImportComposeService — tradução do modelo intermediário para recursos Kubernetes
+status: open
+sprint: 83
+---
+
+O `ImportComposeService` recebe o modelo intermediário produzido pelo parser (issue 01) e um request de configuração editado pelo usuário na tela de revisão, e provisiona todos os recursos Kubernetes no cluster ativo.
+
+Cada serviço do Compose resulta em um Deployment. Quando o serviço declara `ports:`, um Service ClusterIP é criado. Quando há variáveis de ambiente, um ConfigMap (`<service>-config`) e/ou um Secret (`<service>-secret`) são criados conforme a classificação do parser. Quando há named volumes, um PersistentVolumeClaim (`<service>-pvc`) é criado com o StorageClass e tamanho informados pelo usuário (default: StorageClass default do cluster, 1Gi).
+
+Todos os recursos recebem as labels `app.kubernetes.io/part-of: <namespace>` e `app.kubernetes.io/component: <service-name>`.
+
+Serviços com `build:` exigem que o Build Kaniko correspondente (issue 03) já tenha sido executado com sucesso antes da criação dos recursos — a imagem resultante é a referência usada no Deployment.
+
+O serviço tenta criar os recursos de todos os serviços antes de retornar, mesmo que algum falhe. O resultado acumula os recursos criados com sucesso e os que falharam, sem rollback. A lógica de falha parcial segue o padrão de `DeployApplicationResult`.
+
+O Namespace é criado antes de qualquer outro recurso, como pré-condição.

.scratch/sprint-83/issues/03-build-integration.md

@@ -0,0 +1,15 @@
+---
+title: Integração com Build Kaniko para serviços com `build:`
+status: open
+sprint: 83
+---
+
+Serviços do Compose que declaram `build:` precisam ter sua imagem construída antes da criação dos recursos Kubernetes. O GreenCap reutiliza o mecanismo de Build Kaniko existente (ADR 0007): um Job in-cluster no namespace `greencap-system`, com contexto Git apontando para o mesmo repositório fornecido no passo 1 do wizard, e `--dockerfile` derivado do campo `context`/`dockerfile` do Compose.
+
+O nome da imagem produzida usa `image:` do Compose quando declarado junto de `build:`; quando ausente, usa `<service-name>:latest` como default — valor editável pelo usuário na tela de revisão antes de iniciar os builds.
+
+Quando há múltiplos serviços com `build:`, os builds são executados em sequência. Cada build exibe seu log em tempo real na tela de execução (passo 3 do wizard), seguindo o padrão de `BuildView`. Se um build falhar, os builds subsequentes ainda são tentados; o resultado acumula sucesso e falha por serviço.
+
+Um serviço cujo build falhou não tem seus recursos Kubernetes criados — o Deployment não é provisionado sem a imagem.
+
+A integração deve reutilizar a infraestrutura existente de `BuildService` / `BuildJobFactory` sem duplicar lógica de criação de Job Kaniko.

.scratch/sprint-83/issues/04-import-compose-view.md

@@ -0,0 +1,17 @@
+---
+title: ImportComposeView — wizard 3 passos integrado ao DeployApplicationView
+status: open
+sprint: 83
+---
+
+A `DeployApplicationView` existente ganha um segundo modo de entrada: "Deploy from image" (fluxo atual) e "Import Compose" (novo). A seleção entre os dois modos é feita no topo da view, antes de qualquer passo do wizard.
+
+O wizard de Import Compose tem três passos:
+
+**Passo 1 — Fonte e destino:** o usuário informa a URL do Git Repository público, o branch (default: `main`) e o path opcional para o `docker-compose.yml` dentro do repositório (default: `docker-compose.yml`). Também informa o nome do Namespace de destino. Ao avançar, o GreenCap busca e faz o parse do arquivo; erros de fetch ou parse são exibidos inline sem avançar.
+
+**Passo 2 — Revisão:** a tela mostra um painel por serviço com os recursos que serão criados (Deployment, Service, ConfigMap, Secret, PVC), com campos editáveis para: nome da imagem (serviços com `build:`), tamanho e StorageClass dos PVCs, e classificação sensível/não-sensível das variáveis de ambiente. Uma seção consolidada "Diretivas ignoradas" lista o que foi encontrado no Compose mas não traduzido (bind mounts, `depends_on:`, `networks:`, etc.) com aviso visual mas sem bloquear o avanço. Serviços com `build:` exibem o nome da imagem que será produzida, editável.
+
+**Passo 3 — Execução:** para serviços com `build:`, os Jobs Kaniko são criados e acompanhados com log live sequencialmente. Após todos os builds concluírem (com sucesso ou falha), os recursos Kubernetes são criados para os serviços cujos builds tiveram sucesso. Um resumo final mostra o resultado por serviço e por recurso. Em sucesso total, navega automaticamente para a Topologia do Namespace criado. Em falha parcial, permanece na tela de resultado com botão "Ver Topologia" para navegação manual.
+
+Notificações seguem `Notification.Position.BOTTOM_END`. A view é protegida por `PROJECT_DEPLOY_APPLICATION`.

CONTEXT.md

@@ -234,6 +234,10 @@ The source of a Build — a publicly accessible Git repository identified by URL
 _Avoid_: Source code, project, "repository" alone (ambiguous with Repository, the Registry concept)
 
 **Deploy Application**:
-A wizard-guided write operation that creates a new Namespace and provisions the Kubernetes resources needed to run an application from a container image: a Deployment (always), a Service ClusterIP (when a container port is specified), a PersistentVolumeClaim (optional), and an Ingress (optional, requires a port). The image source is a free-text field (`repository:tag`) with suggestions from the active Cluster's internal Registry. Ingress host is auto-suggested as `<namespace>.greencap.local` and editable; IngressClassName is selected from IngressClasses available in the cluster. PVC StorageClass is selected from StorageClasses available in the cluster, with the cluster default pre-selected; access mode is always ReadWriteOnce. On partial failure, GreenCap reports which resources were created and which failed — no rollback is attempted. On success, navigates to the Topologia view of the newly created Namespace. The resulting resources are standard Kubernetes objects with no special GreenCap tracking; they are managed individually through the existing views after creation.
+A wizard-guided write operation that creates a new Namespace and provisions the Kubernetes resources needed to run an application from a container image: a Deployment (always), a Service ClusterIP (when a container port is specified), a PersistentVolumeClaim (optional), and an Ingress (optional, requires a port). The image source is a free-text field (`repository:tag`) with suggestions from the active Cluster's internal Registry. Ingress host is auto-suggested as `<namespace>.greencap.local` and editable; IngressClassName is selected from IngressClasses available in the cluster. PVC StorageClass is selected from StorageClasses available in the cluster, with the cluster default pre-selected; access mode is always ReadWriteOnce. On partial failure, GreenCap reports which resources were created and which failed — no rollback is attempted. On success, navigates to the Topologia view of the newly created Namespace. The resulting resources are standard Kubernetes objects with no special GreenCap tracking; they are managed individually through the existing views after creation. One of two entry modes in `DeployApplicationView` — the other is Import Compose.
 _Avoid_: New project, create project, provision application
 
+**Import Compose**:
+A wizard-guided write operation that translates a `docker-compose.yml` from a public Git Repository into Kubernetes resources and provisions them in a single Namespace. Entry point is the same `DeployApplicationView` as Deploy Application, selected as a second mode. The wizard runs in three steps: (1) Git Repository URL + branch + optional path to the Compose file + Namespace name — GreenCap fetches and parses the file; (2) review screen showing all resources to be created, editable PVC and Secret fields, warnings for unsupported or ignored directives, and pending Builds for services with `build:`; (3) execution — Kaniko Builds run first (one per service with `build:`, live log), then all Kubernetes resources are created, and a result summary is shown. Translation rules: each Compose `service` becomes a Deployment; `ports:` becomes a ClusterIP Service; `environment:` keys matching `PASSWORD`, `SECRET`, `TOKEN`, `KEY`, or `CREDENTIAL` (case-insensitive) go to a Secret (`<service>-secret`), the rest to a ConfigMap (`<service>-config`); named `volumes:` become PersistentVolumeClaims (`<service>-pvc`, defaulting to 1Gi and the cluster's default StorageClass, editable); bind-mount volumes are ignored with a warning; `depends_on:` is ignored with an informative warning; `build:` triggers a Kaniko Build using the same Git Repository as context, pushing to the Cluster's Registry — image name taken from `image:` if declared alongside `build:`, otherwise defaults to `<service-name>:latest` (editable); `image:` without `build:` is used as-is. All generated resources carry `app.kubernetes.io/part-of: <namespace>` and `app.kubernetes.io/component: <service-name>` labels so they appear grouped in Topologia. On full success, navigates to Topologia of the new Namespace; on partial failure, stays on an inline result screen. No rollback on failure. Protected by `PROJECT_DEPLOY_APPLICATION`.
+_Avoid_: Compose deploy, stack import, docker-compose import
+

docs/sprints.md

@@ -18,6 +18,7 @@
 | 80 | Add Cluster dialog — provider Minikube (Docker), aviso OpenShift e comando kubectl copiável | ✅ Concluído |
 | 81 | Testes automatizados: TestContainers + cobertura de services críticos | ✅ Concluído |
 | 82 | Karibu-Testing: testes de views Vaadin — dialogs destrutivos | ✅ Concluído |
+| 83 | Import Compose — wizard 3 passos para importar docker-compose.yml de Git Repository público e provisionar recursos Kubernetes | 🔄 Em andamento |
 
 ---
 

samples/greencap-demo/api/Dockerfile

@@ -0,0 +1,5 @@
+FROM node:20-alpine
+WORKDIR /app
+COPY . .
+EXPOSE 3000
+CMD ["node", "server.js"]

samples/greencap-demo/api/server.js

@@ -0,0 +1,19 @@
+const http = require('http');
+
+const PORT = process.env.APP_PORT || 3000;
+const SERVICE = 'greencap-demo-api';
+
+const server = http.createServer((req, res) => {
+    const body = JSON.stringify({
+        service: SERVICE,
+        status: 'ok',
+        timestamp: new Date().toISOString(),
+        env: process.env.NODE_ENV || 'development',
+    });
+    res.writeHead(200, { 'Content-Type': 'application/json' });
+    res.end(body);
+});
+
+server.listen(PORT, () => {
+    console.log(`[${SERVICE}] Listening on port ${PORT}`);
+});

samples/greencap-demo/docker-compose.yml

@@ -0,0 +1,98 @@
+services:
+
+  postgres:
+    image: postgres:16-alpine
+    ports:
+      - "5432:5432"
+    environment:
+      POSTGRES_DB: taskdb
+      POSTGRES_USER: appuser
+      POSTGRES_PASSWORD: pg-super-secret-password
+    volumes:
+      - postgres-data:/var/lib/postgresql/data
+    restart: unless-stopped
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U appuser -d taskdb"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    ports:
+      - "6379:6379"
+    environment:
+      - REDIS_PASSWORD=redis-secret-token
+    volumes:
+      - redis-data:/data
+    restart: unless-stopped
+
+  api:
+    build:
+      context: ./api
+      dockerfile: Dockerfile
+    ports:
+      - "3000:3000"
+    environment:
+      - NODE_ENV=production
+      - APP_PORT=3000
+      - LOG_LEVEL=info
+      - DB_HOST=postgres
+      - DB_PORT=5432
+      - DB_NAME=taskdb
+      - DB_USER=appuser
+      - DB_PASSWORD=pg-super-secret-password
+      - REDIS_HOST=redis
+      - REDIS_PORT=6379
+      - REDIS_PASSWORD=redis-secret-token
+      - JWT_SECRET_KEY=jwt-signing-secret-key
+      - API_TOKEN=internal-api-access-token
+    volumes:
+      - api-uploads:/app/uploads
+    depends_on:
+      - postgres
+      - redis
+    restart: unless-stopped
+
+  worker:
+    build:
+      context: ./worker
+      dockerfile: Dockerfile
+    environment:
+      - NODE_ENV=production
+      - LOG_LEVEL=info
+      - DB_HOST=postgres
+      - DB_PORT=5432
+      - DB_NAME=taskdb
+      - DB_USER=appuser
+      - DB_PASSWORD=pg-super-secret-password
+      - REDIS_HOST=redis
+      - REDIS_PORT=6379
+      - REDIS_PASSWORD=redis-secret-token
+      - WORKER_CONCURRENCY=4
+      - WORKER_QUEUE=tasks
+    depends_on:
+      - postgres
+      - redis
+    restart: unless-stopped
+
+  nginx:
+    image: nginx:1.27-alpine
+    ports:
+      - "80:80"
+    environment:
+      - NGINX_WORKER_PROCESSES=auto
+    volumes:
+      - ./nginx.conf:/etc/nginx/conf.d/default.conf
+    depends_on:
+      - api
+    restart: unless-stopped
+
+networks:
+  app-network:
+    driver: bridge
+
+volumes:
+  postgres-data:
+  redis-data:
+  api-uploads:

samples/greencap-demo/worker/Dockerfile

@@ -0,0 +1,4 @@
+FROM node:20-alpine
+WORKDIR /app
+COPY . .
+CMD ["node", "worker.js"]