Resumo

  • O GitHub arredonda para cima o tempo de cada job, em minutos inteiros. Somar os segundos primeiro e arredondar uma única vez pode subestimar o consumo.
  • Em um cenário de seis jobs de dez segundos, o total executado é 60 segundos e o faturável é seis minutos. No Linux padrão de dois núcleos x64, a tarifa atual de US$ 0,006 por minuto produz US$ 0,036 de consumo, contra US$ 0,006 de um único job de 60 segundos.

Uma tarefa pequena pode comprar uma embalagem grande. No GitHub Actions, a embalagem mínima é um minuto por job. Quem divide uma verificação em seis execuções de dez segundos não compra apenas os 60 segundos somados. Compra seis arredondamentos.

É o que determina a tabela oficial dos executores: cada job tem seu tempo e sua fração de minuto arredondados para cima. O preço anunciado por minuto ganha sentido econômico depois que se conta quantos cronômetros independentes foram abertos.

A conta que cabe na calculadora

Fixemos um repositório privado e o executor padrão Linux de dois núcleos x64. A tabela atual cobra US$ 0,006 por minuto nessa categoria. Se seis jobs completos durarem exatamente dez segundos cada, cada um conta como um minuto: seis minutos, ou US$ 0,036. Se um job completo durar exatamente 60 segundos, conta como um minuto: US$ 0,006.

São os mesmos 60 segundos de tempo somado dos executores, com uma diferença de US$ 0,03 no valor bruto consumido. O cenário usa durações hipotéticas de jobs completos e a regra oficial. Ele não mede uma migração de workflow. Juntar os trabalhos pode mudar preparação, limpeza, dependências e duração total; seis comandos de dez segundos também não provam que existiram seis jobs de dez segundos.

Essa distinção dá um endereço para a investigação. O comprador precisa do tempo de execução medido do job, não apenas de quanto o comando principal demorou. O painel de duração permite observar tempo executado e minutos faturáveis. Depois é preciso ligar essa informação à categoria do executor, à tarifa vigente e ao relatório de cobrança.

O segundo que vale mais do que os outros

Um job de 61 segundos vira dois minutos. Um de 60 vira um. Já reduzir onze segundos para dez mantém um minuto em ambos os casos. O esforço de otimização e a redução de custo podem seguir caminhos bem diferentes.

Isso muda a conversa sobre desempenho. Uma melhoria pequena na borda do minuto pode reduzir mais quantidade faturada do que uma redução grande em uma tarefa já muito curta. A regra não premia todos os segundos poupados com a mesma quantia. Ela dá preço a degraus.

Há ainda o tempo que a pessoa espera pelo resultado. Executar jobs em paralelo pode encurtar essa espera, mesmo quando o total de tempo de todos os executores permanece alto. Arredondar cada job vem depois dessa soma. Duração até o resultado, tempo total consumido e minutos faturáveis merecem colunas distintas.

A franquia também tem um custo de oportunidade

A explicação atual de faturamento expressa o uso computacional incluído no plano em dinheiro. Usos elegíveis de executores e de computação e memória dos sandboxes de nuvem compartilham esse valor, sem prioridade entre os tipos elegíveis. O saldo se renova no início de cada ciclo. Depois de consumido, o uso adicional é cobrado.

Assim, os US$ 0,036 do exemplo podem primeiro gastar saldo incluído. A despesa adicional em dinheiro aparece quando esse saldo se esgota. Antes disso, o arredondamento usa valor que poderia atender outra demanda elegível. Dizer que todo job curto gera imediatamente uma nova saída de caixa apagaria essa etapa.

Executores padrão hospedados pelo GitHub em repositórios públicos são gratuitos de forma independente dessa franquia. Os executores maiores são cobrados também nos repositórios públicos. A comparação numérica usa deliberadamente um repositório privado e uma categoria específica. Misturar essas modalidades produz uma economia tão fictícia quanto somar segundos antes do arredondamento.

Nem toda embalagem extra é desperdício

A estrutura do Actions tem workflows, jobs e etapas. As etapas de um job usam o mesmo executor; jobs têm seus próprios ambientes e, por padrão, podem rodar em paralelo quando não há dependências. A documentação atual também permite executar determinadas etapas simultaneamente dentro de um job. Paralelismo e multiplicação de jobs, portanto, não são sinônimos obrigatórios.

Ambientes distintos, testes em sistemas diferentes e resultados mais rápidos podem justificar a separação. Colocar trabalhos no mesmo ambiente também permite compartilhar dados. O preço do arredondamento é um componente da escolha, não uma razão para descartar testes ou aproximar tarefas que exigem separação de confiança e permissões.

Para calcular um ganho real, faltam as durações efetivas, as categorias dos executores, a equivalência dos resultados, o tempo de espera, as reexecuções e o saldo incluído usado. A responsabilidade já tem nome: o custo é do proprietário do repositório, não da pessoa que disparou o workflow. Quem desenha as divisões está escolhendo unidades de compra para outra conta. Um job de dez segundos pode ser ótimo. Seis embalagens de um minuto precisam mostrar o que entregam.