No GitHub Actions, qualquer programa pode ser usado como shell

• No GitHub Actions, é possível definir com a palavra-chave shell qual shell será usado para executar um bloco run:
• Em workflows isso é opcional, mas em definições de ações individuais é obrigatório
• O padrão é definido automaticamente conforme o sistema operacional: Linux/macOS usam bash, Windows usa pwsh
• Ao definir explicitamente shell: bash, os seguintes flags padrão também são incluídos: --noprofile --norc -eo pipefail

É possível definir qualquer executável como shell

• Em geral, é fácil supor que os valores permitidos em shell sejam limitados
• Na prática, qualquer executável presente no $PATH pode ser usado como shell
• Se o comando executado não aceitar entrada por arquivo, é preciso passar o argumento especial {0}
• O {0} é automaticamente substituído pelo GitHub pelo caminho de um arquivo temporário

Exemplos experimentais

• Também é possível usar um compilador de C (tcc) como se fosse um shell e executá-lo diretamente
• Também é possível manipular o $PATH para criar e usar um shell bash falso
• O GitHub não se importa se o valor especificado em shell aponta, na prática, para qualquer tipo de executável

Implicações de segurança

• No GitHub Actions, a fronteira entre gravar arquivos e executar algo é difusa (há possibilidade de execução também via GITHUB_ENV, $GITHUB_PATH etc.)
• Mesmo valores bem conhecidos como shell: bash são resolvidos via $PATH, sem usar um caminho fixo de execução como /bin/bash
• Ao contrário do que se poderia imaginar, valores como python também são executados com base em um caminho real, e não apenas como uma referência simples ao toolcache

[tujuc]

Só de ver o repositório github/runner-image, já dá para notar que há bastante pacote instalado que pode ser usado direto....

Se criar a imagem, 1 GB entra fácil....

[GN⁺]

Comentários do Hacker News

• No passado, usei a flag -x do bash para forçar a exibição de todos os comandos executados em um workflow do Actions. Isso é muito útil para depuração
• Um truque não oficial interessante do GitHub Actions que descobri no trabalho é usar curingas para corresponder ao nome do evento repository_dispatch
  • Essa é a única forma de impor workflows reutilizáveis definidos por um pipeline de release centralizado
  • Ao disparar o evento, é fácil identificar o produto e a versão
• Pela minha experiência, quanto menos trabalho você fizer no GitHub Actions, melhor
  • Prefiro codificar a lógica usando um sistema de build (por exemplo, Make) e chamá-lo a partir do GitHub Actions, ou
  • escrever um pequeno programa CLI e chamá-lo a partir do GitHub Actions
  • Depurar localmente é muito mais fácil do que depurar no CI
• Houve uma geração que tinha medo quando recebia o pedido de transformar planilhas em código
  • Essa geração vai ter medo quando receber o pedido de impor disciplina a deploys construídos com GitHub Actions
• O código do Github Actions Runner é fácil de ler
  • Há um lugar específico onde os argumentos padrão para shells/binários populares são definidos
  • ScriptHandler.cs contém todo o código que prepara o ambiente do processo, os argumentos etc.
  • No geral, fiquei positivamente surpreso com a simplicidade desse código
• É possível enganar o shell padrão bash para executar qualquer programa
  • Desde que quem leia a action saiba o que está acontecendo, isso é muito útil
  • Já vi scripts de shell começarem com poucas linhas e crescerem até virar monstros de mais de cem linhas
  • Eu queria recursos como arrays e tipos da stdlib do Python
• Isso dá esperança de que seja fácil executar código Go que roda diretamente tarefas de CI em arquivos YAML de workflow do GitHub
  • goeval ainda não oferece suporte direto a entrada por arquivo
  • É preciso um truque de shell
  • É necessário um pouco de boilerplate
  • Sou o autor do goeval
• Fico me perguntando qual é a vantagem do yaml de CI do Github
• Agora dá para escrever C em CI/CD e chamar isso de trabalho de sistema de baixo nível
  • Provavelmente também daria para escrever assembly