Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.
Sobre estratégias da matriz
Uma estratégia de matriz permite usar variáveis em uma única definição de trabalho para criar automaticamente várias execuções de trabalho que são baseadas nas combinações das variáveis. Por exemplo, você pode usar uma estratégia de matriz para testar seu código em várias versões de uma linguagem ou em vários sistemas operacionais.
Usando uma estratégia da matriz
Use jobs.<job_id>.strategy.matrix
para definir uma matriz de diferentes configurações de trabalho. Dentro da sua matriz, defina uma ou mais variáveis seguidas por uma matriz de valores. Por exemplo, a seguinte matriz tem uma variável denominada versão
com o valor [10, 12, 14]
e uma variável denominada os
com o valor [ubuntu-latest, windows-latest]
:
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
Um trabalho será executado para cada combinação das variáveis possível. Neste exemplo, o fluxo de trabalho irá executar seis trabalhos, um para cada combinação das variáveis os
e versão
.
Por padrão, GitHub Enterprise Server maximizará o número de trabalhos executados em paralelo dependendo da disponibilidade do executor. A ordem das variáveis na matriz determina a ordem em que os trabalhos são criados. A primeira variável que você definir será o primeiro trabalho criado na execução do fluxo de trabalho. Por exemplo, a matriz acima irá criar os trabalhos na seguinte ordem:
{version: 10, os: ubuntu-latest}
{version: 10, os: windows-latest}
{version: 12, os: ubuntu-latest}
{version: 12, os: windows-latest}
{version: 14, os: ubuntu-latest}
{version: 14, os: windows-latest}
Uma matriz gerará no máximo 256 trabalhos por execução do fluxo de trabalho. Este limite aplica-se tanto a executores hospedados em GitHub Enterprise Server quanto a executores auto-hospedados.
As variáveis que você define tornam-se propriedades no contexto da matriz
e você pode fazer referência � propriedade em outras áreas do seu arquivo de fluxo de trabalho. Neste exemplo, você pode usar a matriz.version
e matrix.os
para acessar o valor atual de versão
e os
que o trabalho está usando. Para obter mais informações, consulte "Contextos".
Exemplo: Usando uma matriz de dimensão única
Você pode especificar uma variável única para criar uma matriz de dimensão única.
Por exemplo, o fluxo de trabalho a seguir define a variável versão
com os valores [10, 12, 14]
. O fluxo de trabalho irá executar três trabalhos, um por cada valor na variável. Cada trabalho terá acesso ao valor versão
através do contexto da matrix.version
e passar o valor como node-version
para a ação actions/setup-node
.
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.version }}
Exemplo: Usando uma matriz de múltiplas dimensões
Você pode especificar diversas variáveis para criar uma matriz multidimensional. Um trabalho será executado para cada combinação das variáveis possível.
Por exemplo, o fluxo de trabalho a seguir especifica duas variáveis:
- Dois sistemas operacionais especificados na variável
os
- Três versões do Node.js especificadas na variável
versão
O fluxo de trabalho irá executar seis trabalhos, um para cada combinação das variáveis os
e versão
. Cada trabalho irá definir o valor runs-on
para o valor atual de os
e vai passar o valor atual de versão
para a ação actions/setup-node
.
jobs:
example_matrix:
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
version: [10, 12, 14]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.version }}
Exemplo: Usando contextos para criar matrizes
Você pode usar contextos para criar matrizes. Para obter mais informações sobre os contextos, consulte "Contextos".
Por exemplo, os seguintes gatilhos de fluxo de trabalho no evento repository_dispatch
e usa informações da carga do evento para criar a matriz. Quando um evento de envio de repositório é criado com uma carga como a abaixo, a variável versão
da matriz terá um valor de [12, 14, 16]
. Para obter mais informações sobre o gatilho repository_dispatch
, consulte "Eventos que acionam fluxos de trabalho".
{
"event_type": "test",
"client_payload": {
"versions": [12, 14, 16]
}
}
on:
repository_dispatch:
types:
- test
jobs:
example_matrix:
runs-on: ubuntu-latest
strategy:
matrix:
version: ${{ github.event.client_payload.versions }}
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.version }}
Expansão ou adição de configurações da matriz
Use jobs.<job_id>.strategy.matrix.include
para expandir as configurações da matriz existentes ou para adicionar novas configurações. O valor de incluir
é uma lista de objetos.
Para cada objeto na lista incluir
, os pares chave-valor no objeto serão adicionados a cada uma das combinações da matriz se nenhum dos pares chave-valor sobrescrever qualquer dos valores originais da matriz. Se o objeto não pode ser adicionado a qualquer das combinações matriz, será criada uma nova combinação matriz. Observe que os valores originais da matriz não serão substituídos, mas valores adicionados da matriz podem ser substituídos.
Por exemplo, esta matriz:
strategy:
matrix:
fruit: [apple, pear]
animal: [cat, dog]
include:
- color: green
- color: pink
animal: cat
- fruit: apple
shape: circle
- fruit: banana
- fruit: banana
animal: cat
resultará em seis trabalhos com as seguintes combinações de matriz:
{fruit: apple, animal: cat, color: pink, shape: circle}
{fruit: apple, animal: dog, color: green, shape: circle}
{fruit: pear, animal: cat, color: pink}
{fruit: pear, animal: dog, color: green}
{fruit: banana}
{fruit: banana, animal: cat}
seguindo esta lógica:
{color: green}
é adicionado a todas as combinações de matrizes originais, porque pode ser adicionado sem substituir nenhuma parte das combinações originais.{color: pink, animal: cat}
adicionacolor>pink
apenas para as combinações originais da matriz que incluemanimal: cat
. Isto sobrescrevecolor: green
que foi adicionada pela entradaincluir
anterior.{fruit: apple, shape: circle}
adicionashape: circle
apenas � s combinações da matriz original que incluemfruit: apple
.{fruit: banana}
não pode ser adicionado a qualquer combinação da matriz original sem substituir um valor. Portanto, ele é adicionado como uma combinação da matriz adicional.{fruit: banana, animal: cat}
não pode ser adicionado a qualquer combinação da matriz original sem substituir um valor. Portanto, ele é adicionado como uma combinação da matriz adicional. Não se adiciona � combinação da matriz{fruit: banana}
porque essa combinação não era uma das combinações originais da matriz.
Exemplo: Expandir configurações
Por exemplo, o fluxo de trabalho a seguir irá executar seis trabalhos, um para cada combinação de os
e node
. Quando o valor do trabalho para o os
de windows-latest
e o valor node
de 16
for executado, uma variável adicional chamada npm
com o valor de 6
será incluída no trabalho.
jobs:
example_matrix:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
node: [12, 14, 16]
include:
- os: windows-latest
node: 16
npm: 6
runs-on: ${{ matrix.os }}
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
- if: ${{ matrix.npm }}
run: npm install -g npm@${{ matrix.npm }}
- run: npm --version
Exemplo: Adicionar configurações
Por exemplo, esta matriz gerará 10 trabalhos, um para cada combinação de os
e versão
na matriz, mais um trabalho para o valor de os
de windows-latest
e o valor da versão
de 17
.
jobs:
example_matrix:
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-latest]
version: [12, 14, 16]
include:
- os: windows-latest
version: 17
Se você não especificar nenhuma variável da matriz, todas as configurações em incluir
serão executadas. Por exemplo, o seguinte fluxo de trabalho executaria dois trabalhos, um para cada entrada de incluir
. Isso permite que você aproveite a estratégia da matriz sem ter uma matriz totalmente preenchida.
jobs:
includes_only:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- site: "production"
datacenter: "site-a"
- site: "staging"
datacenter: "site-b"
Excluindo configurações de matriz
Para remover configurações específicas definidas na matriz, use jobs.<job_id>.strategy.matrix.exclude
. Uma configuração excluída só precisa ser uma correspondência parcial para que seja excluída. Por exemplo, o fluxo de trabalho a seguir irá executar nove trabalhos: um trabalho para cada uma das 12 configurações, menos a tarefa excluída que corresponde a {os: macos-latest, version: 12, environment: production}
, e os dois trabalhos excluídos que correspondem a {os: windows-latest, version: 16}
.
strategy:
matrix:
os: [macos-latest, windows-latest]
version: [12, 14, 16]
environment: [staging, production]
exclude:
- os: macos-latest
version: 12
environment: production
- os: windows-latest
version: 16
runs-on: ${{ matrix.os }}
Observação: Todas as combinações de incluir
são processadas depois de excluir
. Isso permite que você use incluir
para voltar a adicionar combinações que foram excluídas anteriormente.
Gerenciando as falhas
Você pode controlar como falhas de trabalho são tratadas com jobs.<job_id>.strategy.fail-fast
e jobs.<job_id>.continue-on-error
.
jobs.<job_id>.strategy.fail-fast
aplica-se � matriz inteira. Se jobs.<job_id>.strategy.fail-fast
estiver definido como verdadeiro
, GitHub Enterprise Server cancelará todos os trabalhos em andamento e agendados na matriz se algum trabalho na matriz falhar. Esta propriedade padrão é verdadeira
.
jobs.<job_id>.continue-on-error
aplica-se a um único trabalho. Se jobs.<job_id>.continue-on-error
for true
, os outros trabalhos na matriz continuarão sendo executados, ainda que o trabalho com jobs.<job_id>.continue-on-error: true
falhe.
Você pode usar jobs.<job_id>.strategy.fail-fast
e jobs.<job_id>.continue-on-error
juntos. Por exemplo, o fluxo de trabalho a seguir dará início a quatro trabalhos. Para cada trabalho, continue-on-error
é determinado pelo valor de matriz.experimental
. Se algum dos jobs com continue-on-error: false
falhar, todos os trabalhos em progresso ou na fila serão cancelados. Se o trabalho com continue-on-error: true
falhar, os outros trabalhos não serão afetados.
jobs:
test:
runs-on: ubuntu-latest
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: true
matrix:
version: [6, 7, 8]
experimental: [false]
include:
- version: 9
experimental: true
Definindo o número máximo de trabalhos simultâneos
Por padrão, GitHub Enterprise Server maximizará o número de trabalhos executados em paralelo dependendo da disponibilidade do executor. Para definir o número máximo de trabalhos que podem ser executados simultaneamente ao usar uma estratégia de trabalho de matriz
, use jobs.<job_id>.strategy.max-parallel
.
Por exemplo, o fluxo de trabalho seguinte será executado um máximo de duas tarefas por vez, mesmo que haja executores disponíveis para executar todos os seis trabalhos de uma só vez.
jobs:
example_matrix:
strategy:
max-parallel: 2
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]