Aplicando alterações

buildprint apply envia as alterações do workspace local de volta para o Bubble. É a etapa final após o sync, edit e check.

buildprint check
buildprint apply

Requisito de check recente

O apply exige um buildprint check recente, bem-sucedido e sem filtros para a base atual do Bubble e as alterações pendentes. Se os arquivos mudarem após o último check, o apply falhará com:

Workspace changed since the last successful `buildprint check`. Run `buildprint check` and retry.

Checks direcionados, checks de caminho (path) e checks filtrados por regras não satisfazem este requisito.

O que o apply faz

1. Verifica a autenticação vinculada e o workspace da branch atual. 2. Garante que o nome da pasta da branch corresponda à branch do git atual (checked-out). 3. Confirma se o app e a branch do workspace coincidem com quaisquer argumentos posicionais passados. 4. Exige o registro de um check recente, a menos que --force-apply seja usado. 5. Executa novamente a etapa de validação interna, a menos que --no-check ou --force-apply sejam usados. 6. Realiza o auto-commit de edições locais não aplicadas quando necessário com Apply from <appId>/<branch>. 7. Monta o snapshot do Bubble e o head local, compara-os (diff) e envia as operações de escrita do Bubble através do Buildprint. 8. Envia definições de tests/ alteradas através da rota de aplicação de testes do Buildprint. 9. Avança o snapshot local do Bubble e as referências publicadas em caso de sucesso.

Se não houver alterações de app ou de teste para aplicar, o comando retorna um resultado JSON unchanged.

Argumentos e sinalizadores (flags)

buildprint apply
buildprint apply <appId> <branch>
buildprint apply --no-check
buildprint apply --allow-large-apply
buildprint apply --force-apply

Os argumentos posicionais appId e branch são apenas verificações de segurança. Eles devem corresponder aos valores do workspace; eles não redirecionam o apply.

Flags:

• --no-check pula a reexecução da validação interna, mas ainda exige o registro de um buildprint check recente e bem-sucedido.

• --allow-large-apply permite o apply quando a base local do Bubble é suspeitamente pequena e o workspace é substancial.

• --force-apply ignora a recência do check, a validação interna e as travas de segurança de grandes aplicações. Use apenas para recuperação excepcional.

Saída

O apply sempre imprime uma linha JSON:

{"ok":true,"appId":"my-app","branch":"test","seconds":1.2,"kind":"applied","applied":3,"summary":{}}

Os valores possíveis para kind são applied e unchanged. Scripts podem processar esta linha diretamente.

Comportamento de auto-commit

Se a árvore de trabalho (worktree) tiver alterações não confirmadas (uncommitted) que diferem do snapshot do Bubble, o apply prepara (stages) apenas os caminhos pendentes de aplicação e cria um commit. Se você desejar uma mensagem de commit personalizada ou um histórico de múltiplos commits, faça o commit manualmente antes de executar o apply.

Quando o apply falha

Causas comuns:

• O workspace mudou desde o último check bem-sucedido. Execute buildprint check novamente.

• O nome da pasta e a branch do git em uso não coincidem. Siga as orientações de cd ou git checkout exibidas.

• O snapshot local do Bubble está ausente. Recrie o workspace da branch com buildprint project clone.

• O Bubble ou o Buildprint rejeita a escrita devido a permissões, escopo da branch ou estado remoto desatualizado. Execute buildprint sync, resolva quaisquer conflitos de merge, execute buildprint check e tente novamente.

Use git status, git diff e git log buildprint/<branch>..HEAD para revisar o que será aplicado.