Resumo Técnico: Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

1. Definição do Problema: Dockerfile Drift (Desvio de Dockerfile)

O desenvolvimento de software moderno depende fortemente de pipelines de Integração Contínua e Implantação Contínua (CI/CD), onde o Docker serve como o padrão de fato para garantir ambientes de build reprodutíveis. No entanto, um problema crítico conhecido como Dockerfile drift compromete essa confiabilidade. O desvio ocorre quando um Dockerfile falha em absorver mudanças feitas no código-fonte da aplicação, levando a uma incompatibilidade entre o script de build e o estado evolutivo do repositório. Diferente de erros de sintaxe, o desvio é um problema de coevolução interna onde a informação para a correção reside dentro do mesmo repositório que produziu a falha.

O desvio se manifesta como caminhos de arquivos incorretos, variáveis de ambiente incompatíveis, especificações de dependências desatualizadas ou mudanças de plataforma. Essas falhas são particularmente difíceas de reparar automaticamente devido a três desafios principais:

• C1 (Extração de Contexto): O estado do build (diretório de trabalho, variáveis de ambiente, conjuntos de arquivos) é determinado pela execução cumulativa de instruções anteriores, não apenas pelo texto do Dockerfile. Métodos existentes baseados em regras e em LLMs frequentemente tratam o Dockerfile de forma isolada, falhando em modelar essas interações dinâmicas.
• C2 (Dependências entre Instruções): As instruções frequentemente dependem de artefatos produzidos por etapas anteriores de formas não óbvias (ex: um comando RUN operando sobre arquivos introduzidos por um COPY anterior ou variáveis definidas por um ARG). Essas dependências não são sintaticamente visíveis isoladamente.
• C3 (Localização de Causas Raiz): Os logs de erro geralmente apontam para a instrução que falhou, mas raramente identificam a causa raiz, que pode advir de uma mudança de código introduzida em um commit anterior.

2. Metodologia: O Framework Cadre

Os autores propõem o Cadre, um framework consciente de contexto projetado para reparar o desvio de Dockerfile ao modelar explicitamente o contexto de build. O insight central de design é que a estrutura do contexto determina a qualidade do reparo mais do que o volume do contexto. O Cadre aborda os três desafios através de quatro fases integradas:

2.1 Dockerfile Drift Extractor (DodeX)

Para resolver a falta de benchmarks realistas, os autores desenvolveram o DodeX, um pipeline que minera instâncias de desvio do mundo real a partir de logs de CI do GitHub Actions. Diferente de datasets de snapshots estáticos, o DodeX captura a configuração completa do build, incluindo argumentos de build dinâmicos, plataformas alvo e o diff exato das mudanças de código que desencadearam a falha. Isso garante que cada instância extraída seja localmente reproduzível.

2.2 Perfilador de Contexto ao Nível de Instrução

Para resolver o C1, o Cadre realiza uma simulação de estado do processo de build do Docker. Ele percorre o Dockerfile instrução por instrução, mantendo um Estado de Contexto ($\sigma$) que rastreia:

• O diretório de trabalho atual ($\delta$).
• Variáveis de ambiente resolvidas ($\varepsilon$).
• O conjunto de arquivos presentes no container ($\Phi$).

Crucialmente, o perfilador utiliza parsers conscientes do sistema de build para 11 ecossistemas principais (ex: Go, Python, npm, Maven). Em vez de tratar comandos RUN como strings opacas, esses parsers inferem dependências de arquivos implícitas (ex: inferindo que go build depende de go.mod e de todos os arquivos *.go no diretório). Isso produz um Mapa de Contexto de Instrução (ICM) vinculando cada instrução ao seu estado preciso de tempo de build.

2.3 Grafo de Dependência Consciente de Contexto (CDG)

Para resolver o C2, o ICM é convertido em um Grafo de Dependência Consciente de Contexto (CDG), um grafo acíclico dirigido ($G = (V, E)$) que torna explícitas as dependências entre instruções:

• Vértices: Incluem nós de instrução ($V_I$) e nós de arquivo ($V_F$).
• Arestas: Incluem arestas sequenciais ($E_S$) representando fluxo de controle e arestas de fluxo de dados ($E_D$) representando dependências de "leitura de" entre arquivos e instruções.
  Este grafo permite que o sistema rastreie caminhos de propagação de falhas através de fronteiras de instrução, identificando como uma mudança em um arquivo fonte (ex: go.mod) invalida uma instrução RUN específica via passos intermediários de COPY ou ARG.

2.4 Fluxo de Trabalho de Reparo Refinado por Contexto

Para resolver o C3 e gerenciar limites de tokens, o Cadre emprega um fluxo de trabalho agêntico de dois passos em vez de um prompt de disparo único:

1. Consulta de Contexto: O LLM recebe o log de erro, o diff do código e uma versão reduzida do CDG. É solicitado que selecione o conjunto mínimo de arquivos relevantes e palavras-chave de grep necessários para o reparo. Este passo filtra o contexto irrelevante antes que o conteúdo dos arquivos seja carregado.
2. Geração de Reparo: O sistema recupera apenas os arquivos selecionados e gera um patch direcionado.
   Esta abordagem evita o transbordamento de prompt (um modo de falha comum em métodos concorrentes de LLM) e garante que o modelo foque em evidências causalmente relevantes.

3. Principais Contribuições

• Framework Cadre: Um novo framework de reparo fundamentado no insight de que a estrutura do contexto é mais valiosa que o volume. Ele integra um perfilador de contexto de estado, um grafo de dependência e um fluxo de trabalho de LLM de dois passos.
• DodeX e Benchmark $D^3$: A criação do DodeX, um pipeline para extração de instâncias de desvio com configurações completas de build, e do $D^3$, o primeiro benchmark de desvio de Dockerfile onde todas as 1.040 instâncias são localmente reproduzíveis usando parâmetros exatos de execuções originais de CI.
• Avaliação Empírica: Uma avaliação abrangente comparando o Cadre contra baselines baseados em regras (Parfum), baselines baseados em recuperação (FlakiDock) e LLMs puros (Vanilla-LLM).

4. Resultados Experimentais

O framework foi avaliado no benchmark $D^3$ (653 instâncias executáveis após filtragem por timeouts de rede).

• Efetividade de Reparo: O Cadre alcançou uma taxa de reparo de 35,22%, superando o baseline baseado em regras (Parfum, 9,34%) em 2,78$\times$ e o melhor baseline baseado em LLM (Vanilla-LLM, 28,48%) em 1,24$\times$.
• Eficiência de Tokens e Robustez: O Cadre eliminou totalmente as falhas de transbordamento de prompt ($|F_r| = 0$), mantendo 95,25% dos prompts abaixo de 30k tokens. Em contraste, métodos de LLM concorrentes falharam em gerar patches em 41–58 casos devido à excedência de limites de contexto.
• Robustez ao Desvio Obsoleto (Stale Drift): À medida que as instâncias de desvio se tornavam "obsoletas" (persistindo através de múltiplos commits), o desempenho das abordagens baseadas apenas em diff degradava significativamente. A 5+ commits de distância, o Cadre manteve uma taxa de sucesso de 25,9% comparado a 19,7% para o melhor baseline, demonstrando que o CDG fornece um sinal estrutural robusto à distância de commits.
• Estudos de Ablação: Remover o CDG reduziu a taxa de reparo em 4,29 pontos percentuais, enquanto remover o fluxo de trabalho de dois passos reduziu a taxa em 3,67 pontos e reintroduziu falhas de transbordamento de prompt. Os componentes foram considerados mutuamente reforçadores.

5. Significância e Alegações

O artigo alega que a modelagem explícita de dependências é um sinal de reparo durável. Os autores argumentam que a vantagem das abordagens conscientes de contexto sobre os métodos baseados apenas em diff ou recuperação aumenta conforme o desvio envelhece através dos commits. O estudo sugere que a manutenção de Infraestrutura como Código (IaC) consciente de contexto é uma direção produtiva para o desenvolvimento de ferramentas futuras.

Os autores observam modestamente as limitações: o CDG é baseado em análise estática e não pode capturar totalmente fatores de tempo de execução, como estados de registro de pacotes ou condições de rede, que explicam algumas falhas não resolvidas. Adicionalmente, o benchmark é limitado a repositórios públicos do GitHub. No entanto, o trabalho estabelece que modelar explicitamente o contexto de build — especificamente o fluxo de dados e controle entre instruções — é crítico para automatizar o reparo de configurações de software em evolução.