O Devin agora tem acesso a máquinas virtuais macOS. Isso significa que ele já pode compilar e testar aplicativos iOS e macOS.
Se você usa uma implantação Dedicated SaaS, entre em contato com seu account team para ativar as VMs macOS.
runs-on no seu blueprint indica ao Devin em qual plataforma fazer o build e a execução, e cada plataforma tem seu próprio snapshot.
As principais diferenças em relação ao Linux são o shell, a organização do sistema de arquivos e o gerenciador de pacotes:
Iniciando uma sessão no macOS
- Blueprint: adicione
runs-on: macos para que o snapshot do repositório seja criado para macOS (veja abaixo).
- Slack: use o bang command
!mac para iniciar uma sessão em uma VM macOS.
- API: defina
platform: "macos" ao criar uma sessão, um agendamento ou uma automação. Consulte a referência da API.
Escrevendo blueprints para macOS
runs-on: macos no nível superior:
Para fazer o build do mesmo repositório para mais de uma plataforma, escreva cada plataforma como um documento YAML separado, delimitado por ---. Cada documento declara seu próprio rótulo runs-on. Consulte o aviso YAML multidocumento no guia de blueprints para mais informações sobre esse formato.
Cada documento gera um build do snapshot separado para sua plataforma. As sessões são inicializadas a partir do snapshot específico de cada plataforma.
O YAML de nível superior deve ser um mapping, não uma sequência. Escrever o exemplo acima como uma única lista (- runs-on: default / - runs-on: macos) é rejeitado pelo backend. Use o separador --- mostrado acima.
runs-on é mapeado para uma configuração de máquina registrada na sua conta:
Você pode especificar runs-on como uma string ou uma lista:
A sintaxe de lista executa comandos idênticos em todas as plataformas da lista. Use-a apenas quando os comandos forem de fato multiplataforma (por exemplo, npm install). Para comandos específicos de cada plataforma (como apt-get no Linux ou brew no macOS), use o formato de múltiplos documentos. Selecionando uma versão do Xcode
xcode-select. Para usar outra versão instalada em um único comando, defina DEVELOPER_DIR:
Use /usr/bin/xcodebuild (o shim que respeita DEVELOPER_DIR) em vez de um xcodebuild resolvido a partir do Contents/Developer/usr/bin de um Xcode específico no PATH, que reporta a própria versão independentemente de DEVELOPER_DIR.
Ou altere o padrão para a sessão inteira:
Inclua no seu blueprint a versão de que você precisa para que toda sessão comece com a toolchain correta.
Comportamento da sessão no macOS
sed -i exige um argumento (sed -i ''), e ferramentas GNU como gsed, gdate e greadlink vêm da fórmula coreutils do Homebrew.
Os repositórios são clonados em /Users/devin/repos/<repo-name>, e os arquivos que você importa para uma sessão são gravados em /Users/devin/.files/.
Os segredos ficam disponíveis como variáveis de ambiente durante as sessões ($SECRET_NAME), assim como no Linux. É assim que você fornece chaves de API do App Store Connect, credenciais de assinatura ou tokens de registro privado:
As sessões fazem um snapshot em disco ao entrar em sleep. Tudo o que está em disco sobrevive ao wake: ferramentas instaladas, repos clonados, caches de build, dados derivados. Processos em execução, não: servidores de desenvolvimento, simuladores e watchers precisam ser reiniciados depois que a sessão acorda.
O Computer Use funciona em sessões macOS: o Devin ganha um desktop macOS completo, com Chrome, mouse e teclado, podendo testar tanto apps nativos do macOS quanto web apps e gravar o que faz. O Devin usa a tecla Command para os atalhos do macOS (⌘C, ⌘V, ⌘Tab), e não a tecla Control.
O Devin pode iniciar e controlar o iOS Simulator diretamente:
A aba iOS Simulator no workspace da sessão transmite o simulador em execução, permitindo que você acompanhe em tempo real o Devin tocando pelas telas do seu app. É o equivalente da Apple ao suporte a emulador Android.
Caches de build aquecidos
maintenance no environment.yml para preaquecer o cache.
Os Swift packages resolvidos, os CocoaPods e o DerivedData permanecem no snapshot, de modo que novas sessões começam a partir de um build incremental.
Builds que buscam dependências no CocoaPods, no Swift Package Manager, no Firebase ou em um registro privado precisam que esses hosts estejam acessíveis. Se a sua organização opera com uma política de rede restrita, verifique se a lista de permissões do macOS cobre os mesmos registros usados pelos seus builds no Linux. As duas são configuradas separadamente, e uma entrada ausente geralmente se manifesta como uma falha de resolução de dependências ou de TLS no meio de um build.
VMs macOS não têm virtualização de hardware aninhada, portanto o runtime de contêineres precisa recorrer à emulação por software do QEMU (TCG). O Colima detecta isso e alterna para a emulação automaticamente:
A VM leva de dois a quatro minutos para ficar utilizável, e a primeira inicialização pode expirar esperando o SSH enquanto o guest emulado sobe a rede, então execute o colima start novamente se ele falhar. Depois disso, os contêineres rodam de 15 a 25x mais devagar na CPU do que nativamente, levando alguns segundos para iniciar cada um; os pulls acontecem na velocidade da rede do host. Isso é aceitável para um contêiner de linting ou empacotamento, mas sofrido para compilação. Para trabalhos que dependem muito de contêineres, use uma sessão Linux ou aponte a sessão macOS para um daemon Docker remoto.
Não instale o Xcode em um blueprint a menos que seja necessário
DEVELOPER_DIR ou xcode-select. Se precisar de uma versão diferente ou de uma beta, você pode armazenar um Apple ID como segredo e fazer o blueprint baixar essa versão, ao custo de um build muito mais lento.
Os builds ficam muito mais lentos na primeira sessão após um rebuild do snapshot. O DerivedData foi reconstruído do zero. Adicione uma etapa build-for-testing ao maintenance para que o snapshot já inclua um build aquecido.
O xcodebuild escolhe a toolchain errada. Verifique xcode-select -p e defina DEVELOPER_DIR explicitamente na etapa do blueprint.
Um destino não é encontrado. Execute xcrun simctl list devices available para ver o que os runtimes instalados realmente oferecem e ajuste o nome e o SO em -destination de acordo.
A resolução de dependências trava ou falha com um erro de TLS. Provavelmente o host não está na lista de permissões de rede da sua organização para macOS. Consulte Acesso à rede. 
