v0.7.9 — Topologia: o nó passa a dizer o que está errado

Topologia — o nó passa a dizer o que está errado

A Topologia é a tela que explica o cluster antes de o usuário entender qualquer conceito de Kubernetes. Até aqui, ela pintava o corpo de cada nó pelo tipo de recurso e deixava o estado numa borda de 3px — o fundo saturado disputava atenção com o único sinal que importava, e o motivo do problema só aparecia depois de clicar no nó. Um Pod quebrado era um contorno avermelhado sem nome.

A codificação inteira trocou de canal:

• A cor agora significa estado, e nada mais — verde para o que está rodando, cinza para quem não tem estado próprio a reportar, âmbar para degradado, vermelho para problema. Degradação e problema desenham a borda mais grossa, para serem achados de relance num grafo denso.
• O tipo virou ícone — cada nó exibe o ícone do seu recurso, com o kind também escrito por extenso sob o nome.
• O status está escrito no nó — num badge da cor da severidade: CrashLoopBackOff, ImagePullBackOff, 0/1 ready. Só aparece quando há atenção a pedir, então um grafo saudável continua silencioso e o nó quebrado é o que fala.

Duas correções vieram de brinde, por consequência direta da regra nova: Service e Ingress deixam de ser permanentemente verdes — eles roteiam tráfego, não têm saúde própria, e o verde sugeria uma confirmação que nunca esteve lá —, e um PersistentVolumeClaim Lost passa a alarmar em vermelho, onde antes desenhava o mesmo cinza de um volume saudável. Perda de dados deixou de ser subnotificada.

Decisões e alternativas descartadas em docs/adr/0022.

Status do Pod deixa de exibir a fase crua

A listagem de Pods e a Topologia passam a mostrar o estado real do Pod em vez da fase reportada pelo Kubernetes. Um Pod em CrashLoopBackOff aparecia como Running, porque a fase é Running — a informação estava tecnicamente correta e praticamente inútil. Agora CrashLoopBackOff, ImagePullBackOff e ContainersNotReady aparecem com nome próprio e severidade própria, alimentando a cor nos dois lugares.

Deploy a partir de uma pasta do seu computador

Os wizards Deploy from Dockerfile e Deploy from Compose passam a aceitar upload de uma pasta local como contexto de build, além do clone de um repositório Git. Quem está experimentando um projeto que ainda não subiu para lugar nenhum não precisa mais criar um repositório só para testar.

Correções

• "Go to resource" nos nós de Pod e PodGroup da Topologia agora leva ao Pod certo, em vez de abrir a listagem sem filtro.
• Navegação de CronJobs → Jobs e Jobs → Pods passa a montar os parâmetros corretamente, corrigindo links que chegavam ao destino sem o filtro aplicado.
• Versão da imagem de release deixa de sair com o sufixo -dev.

Imagem

docker pull ghcr.io/greencapk8s/platform:0.7.9

Ver PR #23 e docs/sprints.md para detalhes completos.

Changelog completo: v0.7.8...v0.7.9

v0.7.8 — Instalação mais rápida: imagem da plataforma em registry público

Sprint 106 — imagem da plataforma no GHCR

O passo mais pesado da instalação — o build local da imagem — deixou de rodar em toda execução. A imagem da plataforma agora é publicada em ghcr.io/greencapk8s/platform a cada release, e o setup.sh puxa a imagem pronta em vez de construí-la.

• Instalação mais rápida — em amd64, o setup.sh baixa ghcr.io/greencapk8s/platform:latest (imagem pública, sem autenticação) e a carrega no cluster via minikube image load, no lugar do docker build + push ao registry interno.
• Fallback automático — em arm64 (Apple Silicon), com BUILD_LOCAL=true, ou se o pull falhar, o build local acontece de forma transparente — a instalação nunca trava.
• Fixar versão — PLATFORM_IMAGE_TAG=X.Y.Z ./setup/setup.sh puxa uma versão específica (padrão: latest).
• Publicação por CI — novo workflow publish-image.yml publica X.Y.Z + latest a cada push de tag v*.

O registry interno do cluster permanece, usado pelos builds de Templates (Kaniko) e pela view de Registry.

Decisões e trade-offs em docs/adr/0019.

Imagem

docker pull ghcr.io/greencapk8s/platform:0.7.8

Ver PR #21 e docs/sprints.md para detalhes completos.

Changelog completo: v0.7.7...v0.7.8

v0.7.7 — Sprints 104-105 + primeiro contato open source

Sprints 104-105

• Sprint 104 — username no header; Developer Experience como 1ª seção do menu (New Application incorporado); fix de duplicação nos 4 wizards de deploy
• Sprint 105 — Topologia: setas de dependência entre serviços (ServiceDependency, inferidas de variáveis de ambiente diretas ou resolvidas de ConfigMap/Secret) + suporte a StatefulSet como nó

Infra / setup

• fix — setup.sh reaproveita DB_PASSWORD e GREENCAP_ENCRYPTION_KEY do secret existente em reruns, evitando falha de autenticação do Postgres em reinstalações sobre o mesmo volume

Primeiro contato / open source

• README reescrito em inglês com vitrine de produto + screenshots (Templates Catalog, Topologia, Deployments)
• LICENSE Apache-2.0 — o repositório agora é oficialmente licenciado (uso e contribuição destravados)
• Arquivos de contribuição: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, templates de issue/PR
• Social preview image do repositório

Ver PR #19 e docs/sprints.md para detalhes completos.

Changelog completo: v0.7.6...v0.7.7

v0.7.6

Sprints 101 a 103

• Sprint 101 — bug fixes do selector de Namespace no header: refresh do combobox após Deploy Application/Dockerfile/Compose; seleção preservada no full reload (F5)
• Sprint 102 — Templates Catalog: ação "Open Topology" no card de Template instalado — troca o Namespace ativo e navega para a Topologia
• Sprint 103 — Templates Catalog: ação "Uninstall Template" no card instalado — deleta apenas o Namespace do Template (ADR 0017), com dialog type-to-confirm e estado transitório "Uninstalling…" com auto-heal via polling
• fix — Docker vira pré-requisito manual no macOS (remove auto-provisionamento via Colima)

Ver PR #18 e docs/sprints.md para detalhes completos.

v0.7.5 — Sprint 100: suporte nativo a macOS no setup.sh

Sprint 100 — Suporte nativo a macOS no setup.sh + validação via GitHub Actions

Esta release traz suporte nativo real a macOS no instalador plug-and-play, além de workflows de CI que validam o setup.sh de ponta a ponta em Linux e macOS.

Destaques

• Suporte nativo a macOS no setup.sh: install_docker/kubectl/minikube/helm ganham branch macOS via Homebrew (brew install colima docker kubectl minikube helm). Docker é provido por Colima headless — não Docker Desktop (GUI, inviável para o fluxo plug-and-play e CI). ensure_homebrew() auto-instala o Homebrew se ausente (NONINTERACTIVE=1). O mecanismo Linux (curl/apt) permanece inalterado. Raciocínio completo na ADR 0016.
• Modo não-interativo por variáveis de ambiente: AUTO_INSTALL, PROFILE_CHOICE, NODES/CPUS/MEMORY, e CONFIRM no teardown.sh — estende o padrão já usado por GREENCAP_ENCRYPTION_KEY/DB_PASSWORD, necessário para automação em CI.
• Novo workflow setup-script-validate.yml: matrix ubuntu-24.04 (fluxo completo: setup → reachability com retry → teardown) e macos-14 (INSTALL_ONLY=true — valida os instaladores Homebrew, sem provisionar cluster). docker-compose-validate.yml migrado de ubuntu-latest para ubuntu-24.04 (tags *-latest são realocadas pelo GitHub sem aviso).

Correções (descobertas em execuções reais de CI)

• ${AUTO_INSTALL,,} (Bash 4+) quebrando no /bin/bash 3.2 do macOS → substituído por case portável.
• sed -i sem -i.bak quebrando no BSD sed do macOS.
• curl de reachability com 503 por corrida do ingress-nginx sincronizando a config → retry 10x/5s.
• docker/Dockerfile baixava o Helm CLI fixo em linux-amd64, quebrando em build arm64 → fix via ARG TARGETARCH.

Nota de plataforma

Runners macos-* hospedados padrão do GitHub Actions não suportam virtualização aninhada — colima start nunca teria sucesso ali, independente do setup.sh. Por isso o job macOS da CI é INSTALL_ONLY. O suporte real a macOS para uso local do usuário permanece completo.

---

Changelog completo: v0.7.4...v0.7.5

v0.7.4 — Templates Catalog

Sprint 98 — Templates Catalog

Catálogo de Templates em Developer Experience com deploy em um clique, consumindo o índice catalog.json do repositório greencap-templates (ADR 0015).

• Índice catalog.json + manifest template.yaml por Template, buscados via HTTP raw
• Build automático via Kaniko para componentes sem imagem pública, publicando no Registry interno do Cluster
• "Installed" por Cluster (Namespace de nome fixo no índice)
• Deploy aborta no primeiro conflito, sem rollback

PR: #14

Outras mudanças

• Ajustes no local-path-provisioner do ambiente de demonstração (samples/greencap-demo/)
• Documentação: CONTEXT.md, ADR 0015, docs/sprints.md

v0.7.3 - Hotfix: Deploy from Dockerfile build status polling

Main Changes

• Fixed false "Build failed" notification in Deploy from Dockerfile: the background polling that checks the Kaniko build Job status could lose its authenticated context. AsyncTasks.schedulePolling dispatched each recurring tick through DelegatingSecurityContextExecutor.execute(...) called by the shared clock thread, which never has an authenticated user — this made Kubernetes credential resolution fail mid-poll (Unable to resolve Kubernetes credentials: no authenticated user), aborting the status check and reporting a failure even when the Kaniko Job had completed successfully and the image was already pushed to the registry.
• Isolated build log fetching from status checking: DeployFromDockerfileView now reads the build pod's logs in its own try/catch, so a transient log-read failure (e.g. a short-lived Kaniko container tearing down) no longer aborts the real Job status check.

Impact

This fixes every view that relies on AsyncTasks.schedulePolling for recurring background checks: BuildLogsView, DeployFromDockerfileView, ImportComposeView, MainLayout, and PodLogsView.

v0.7.2 - Kubernetes-Native RBAC, Helm & Operator Management

Release notes:

Kubernetes-Native RBAC, Helm & Operator Management for GreenCap K8s

Overview

This release replaces GreenCap's internal permission system with native Kubernetes RBAC and adds full lifecycle management for Helm releases and Operators
(OLM), alongside a more accessible cluster registration flow and a consolidated async execution model across the platform.

What's New

• Kubernetes RBAC Authorization: internal permission system replaced by native Kubernetes RBAC — every user is backed by a ServiceAccount +
  ClusterRoleBinding, so access control lives in the cluster itself, not in GreenCap's database
• Security Hardening: fail-closed authorization for users without a provisioned ServiceAccount, plus a fix for authentication context not propagating
  into virtual threads (affected all async data loading — dashboards, namespaces, deploy wizards, topology, logs)
• Helm Management: list Helm Releases with full details (Notes/Values/Manifest), install/upgrade/uninstall via Helm CLI, manage chart Repositories per
  cluster, and a new "Deploy from Helm" wizard
• Kubernetes Operators (OLM): browse the Operator catalog and install/uninstall Operators directly from a new Developer Experience section in the
  sidebar
• Cluster Registration via Token + URL: register a cluster using just the API server URL and a bearer token — no kubeconfig file required, ideal for
  managed clusters (GKE/EKS/AKS)
• PersistentVolume Delete: remove PVs directly from the UI, with a guard preventing deletion of volumes still Bound to a claim
• YAML Editor Upgrade: manifests and Helm values are now edited with a CodeMirror 6 editor — syntax highlighting, line numbers, and dark/light theme
  sync
• AsyncTasks: a single, consolidated entry point for asynchronous execution across the app, replacing per-view schedulers and threads

Benefits

1. Simpler Security Model: no separate permission system to maintain — Kubernetes RBAC is the single source of truth for authorization
2. Faster Onboarding for Managed Clusters: Token + URL registration removes the friction of locating and uploading a kubeconfig file
3. Full Helm & Operator Lifecycle in One Place: no need to leave GreenCap to manage Helm releases or cluster Operators
4. More Reliable Async Behavior: authentication context now propagates correctly across all background loading, closing a class of silent failures
5. Better Editing Experience: a real code editor for YAML instead of plain text areas

v0.5.0 - GreenCap K8s TechDocs

TechDocs Implementation for GreenCap K8s

Overview

This version introduces a comprehensive technical documentation system (TechDocs) for the GreenCap K8s platform using MkDocs Material.

What's New

• Automated Deployment: TechDocs is now part of the minimal installation setup and deploys automatically with every GreenCap K8s environment
• Material Design: Modern, responsive UI using MkDocs Material theme with green accent colors matching the GreenCap branding
• Component Documentation: Detailed documentation for all platform components including:
  • Kubernetes Dashboard
  • Monitoring Stack (Prometheus + Grafana)
  • Harbor Container Registry
  • GitLab CI/CD
  • PostgreSQL Database
• Easy Access: Available at http://tech-docs.greencap:30001 through the NGINX ingress controller

Benefits

1. Centralized Documentation: All platform documentation in one easily accessible location
2. Self-Documenting: Documentation is deployed alongside the platform
3. Offline Access: Documentation available without internet connection
4. Improved Onboarding: New users can quickly understand the platform components

v0.4.6 - Removing the use of the latest versions.

Main Changes

• Removing the use of the latest versions for all major components (Cilium, GitLab, Harbor, Kind, Metrics Server, Prometheus, Postgres, Apache)