• Tipos de corredores
  • Compartilhada corredores
    • partilhada Como corredores de escolher emprego
    • Ativar compartilhada corredores
    • Desativar compartilhada corredores
  • Grupo de corredores
    • Criar um grupo corredor
    • Ver e gerir um grupo de corredores
    • Pausar ou remover um grupo corredor
  • Específico corredores
    • Crie um determinado corredor
    • Ativar um determinado corredor para um projeto específico
    • Impedir que um determinado corredor de estar activado para outros projetos
• limpar Manualmente o corredor cache
• máximo do Conjunto de trabalho de tempo limite para um corredor
• cuidado com a informação sensível
  • Evitar corredores de revelar informações confidenciais
  • Garfos
  • vetores de Ataque em corredores
  • Redefinir o corredor de registro de token para um projecto
• Determinar o endereço IP de um corredor
  • Determinar o endereço IP de um corredor
  • Determinar o endereço IP de um determinado corredor
• Use tags para limitar o número de trabalhos que utilizam o corredor
  • corredor é executado apenas tagged postos de trabalho
  • corredor é permitida a execução de untagged postos de trabalho
• Configurar corredor comportamento com variáveis
  • Git estratégia
  • Git submodule estratégia
  • Git checkout
  • Git limpa os sinalizadores
  • Git fetch extra bandeiras
  • Superficial clonagem
  • compilação Personalizada diretórios
    • Manipulação de simultaneidade
    • Aninhados caminhos
  • Trabalho de estágios tentativas
• chamadas de Sistema não disponível GitLab.com compartilhado corredores
• Artefato e as configurações de cache

Em GitLab CI/CD, corredores de executar o código definido no .gitlab-ci.yml.Um corredor é um agente leve e altamente escalável que pega um trabalho de IC através da API coordenador do GitLab CI/CD, executa o trabalho, e envia o resultado de volta para a instância GitLab.

corredores são criados por um administrador e são visíveis no UI GitLab.Corredores podem ser específicos para certos projetos ou disponíveis para todos os projetos.

Esta documentação está focada no uso de corredores no GitLab.Se precisar de instalar e configurar a execução do GitLab, veja a documentação da execução do GitLab.

tipos de corredores

na interface GitLab existem três tipos de corredores, baseados em quem você quer ter acesso:

• corredores compartilhados estão disponíveis para todos os grupos e projetos em uma instância GitLab.
• corredores de grupo estão disponíveis para todos os projetos e subgrupos de um grupo.corredores específicos estão associados a projetos específicos.Tipicamente, corredores específicos são usados para um projeto de cada vez.

corredores compartilhados

corredores compartilhados estão disponíveis para cada projeto em uma instância GitLab.

Use corredores compartilhados quando você tem várias tarefas com requisitos semelhantes. Em vez de ter vários corredores em marcha lenta para muitos projetos, você pode ter alguns corredores que handlemultiple projetos.

Se você estiver usando um auto-gerido instância do GitLab:

• O administrador pode instalar e registrar compartilhada corredores bygoing do seu projeto de Definições > CI/CD, expandindo os Corredores seção,e clicando em Mostrar o corredor instruções de instalação.Estas instruções também estão disponíveis na documentação.
• o administrador também pode configurar um número máximo de pipeline compartilhada minutos para cada grupo.

Se estiver a utilizar GitLab.com:

• você pode selecionar a partir de uma lista de corredores compartilhados que o GitLab mantém.os corredores partilhados consomem as minutas dos oleodutos incluídas na sua conta.

como os corredores partilhados escolhem as tarefas

os corredores partilhados processam as tarefas usando uma fila de utilização justa. Esta fila evita que os projectos criem centenas de postos de trabalho e utilizem todos os recursos disponíveis para os corredores.

o algoritmo de Fila de justa utilização atribui tarefas baseadas nos projectos que têm o menor número de tarefas já em execução em corredores partilhados.

Exemplo 1

Se esses trabalhos estão na fila:

• Tarefa 1 para o Projeto 1
• Trabalho 2 para o Projeto 1
• Trabalho 3 para o Projeto 1
• a Tarefa 4, para o Projeto 2
• Jó 5 para o Projeto 2
• Trabalho de 6 para Projeto 3

O uso justo algoritmo atribui tarefas nesta ordem:

1. Tarefa 1 é escolhido primeiro, porque ele tem o menor número de trabalho a partir de projetos sem os trabalhos em execução (isto é, todos os projetos).
2. Job 4 é o próximo, porque 4 é agora o menor número de trabalhos de projetos sem trabalhos em execução (o projeto 1 tem um trabalho em execução).
3. Job 6 é o próximo, porque 6 é agora o menor número de empregos de projetos sem empregos em execução (projetos 1 e 2 têm empregos em execução).
4. Job 2 é o próximo, porque, de projetos com o menor número de Empregos em execução (cada um tem 1), é o menor número de empregos.
5. o trabalho 5 é o próximo, porque o projecto 1 tem agora 2 postos de trabalho em funcionamento e o emprego 5 é o menor número restante de postos de trabalho entre os projectos 2 e 3.Finalmente é o trabalho 3 … porque é o único trabalho que resta.

Exemplo 2

Se esses trabalhos estão na fila:

• Tarefa 1 para o Projeto 1
• Trabalho 2 para o Projeto 1
• Trabalho 3 para o Projeto 1
• a Tarefa 4, para o Projeto 2
• Jó 5 para o Projeto 2
• Trabalho de 6 para Projeto 3

O uso justo algoritmo atribui tarefas nesta ordem:

1. Tarefa 1 é escolhido primeiro, porque ele tem o menor número de trabalho a partir de projetos sem os trabalhos em execução (isto é, todos os projetos).terminamos o trabalho 1.
2. Job 2 é o próximo, porque, tendo terminado o Job 1, todos os projetos têm 0 jobs funcionando novamente, e 2 é o menor número de job disponível.
3. Job 4 é o próximo, porque com o projeto 1 executando um trabalho, 4 é o menor número de projetos sem empregos (projetos 2 e 3).terminamos o trabalho 4.
4. A tarefa 5 é a seguir, porque tendo terminado a tarefa 4, O Projeto 2 não tem nenhuma tarefa funcionando novamente.
5. Job 6 é o próximo, porque o projeto 3 é o único projeto deixado sem nenhuma tarefa em execução.finalmente escolhemos o trabalho 3… porque, mais uma vez, é o único trabalho que resta.

activar os corredores partilhados

em GitLab.com, corredores compartilhados são habilitados em todos os projetos por omissão.

em instâncias autogeridas do GitLab, um administrador deve instalá-las e registrá-las.

Você também pode permitir corredores compartilhados para projetos individuais.

para activar corredores partilhados:

1. vai para as configurações do projecto > CI/CD e expande a secção de corredores.
2. Seleccione Activar os corredores partilhados para este projecto.

desactivar os corredores partilhados

pode desactivar os corredores partilhados para projectos individuais ou para grupos.Você deve ter permissões de dono para o projeto ou grupo.

para desactivar os corredores partilhados para um projecto:

1. vai para as configurações do projecto > CI/CD e expande a secção de corredores.
2. na área dos corredores partilhados, seleccione a opção Activar os corredores partilhados para este projecto, para que a comutação esteja acinzentada.

os corredores partilhados estão automaticamente desactivados para um projecto:

• Se a configuração dos corredores partilhados para o grupo-mãe estiver desactivada, e
• Se ultrapassar esta configuração não for permitida a nível do projecto.

Para desativar compartilhada corredores de um grupo:

1. Vá para as Configurações do grupo > CI/CD e expandir os Corredores seção.
2. na área dos corredores partilhados, desligue os corredores partilhados para esta opção de grupo.
3. opcionalmente, para permitir que os corredores partilhados sejam activados para projectos ou subgrupos individuais, carregue em permitir que os projectos e subgrupos sobreponham a configuração do grupo.

marca definida é executada e executada.

Exemplo 2:

1. o corredor está configurado para executar tarefas não marcadas e não tem marcas definidas.
2. uma tarefa que não tenha marcas definidas é executada e executada.
3. a second job that has a docker tag defined is stuck.

configurar o comportamento de execução com variáveis

pode usar variáveis de CI / CD para configurar o comportamento git corredor ou para tarefas individuais:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_DEPTH (rasa clonagem)
• GIT_CLONE_PATH (compilação personalizada diretórios)

Você também pode usar variáveis para configurar quantas vezes runnerattempts certas fases da execução do trabalho.

estratégia Git

Você pode definir o GIT_STRATEGY usado para buscar o repositório de conteúdo, eitherglobally ou por trabalho variables seção:

variables: GIT_STRATEGY: clone

Existem três valores possíveis: clonefetch e none. Se deixado indeterminado, jobs usam a configuração do pipeline do projeto.

clone é a opção mais lenta. Clones o repositório do zero para cada trabalho, garantindo que a cópia de trabalho local é sempre impecável.Se um worktree existente é encontrado, ele é removido antes da clonagem.

é mais rápido porque reutiliza a cópia de trabalho local (recuando paraclone se não existir). git clean é usado para desfazer quaisquer alterações feitas pela última tarefa, egit fetch é usado para recuperar commits feitos após a última tarefa executada.

no entanto, requer o acesso à árvore de trabalho anterior. Este workswell ao usar o shell ou docker executor porque thesetry para preservar worktrees e tentar voltar a usá-los por padrão.

isto tem limitações ao usar o executor da máquina do Docker.

It does not work for the kubernetes executor,but a feature proposal exists.O executor kubernetes executor sempre clones em um diretório temporário.

a Git strategy of none also Re-uses the local working copy, but skips all Gitoperations normally done by GitLab. Os programas pré-clones de execução do GitLab também são ignorados,se estiverem presentes. Esta estratégia pode significar que você precisa para adicionar fetch e checkout commandsto o .gitlab-ci.yml script.

pode ser usado para trabalhos que operam exclusivamente em artefatos, como um trabalho de implantação.Os dados do repositório Git podem estar presentes, mas provavelmente estão desactualizados. Você deve apenas sobre os arquivos trazidos para a cópia de trabalho local do cache ou artefatos.

git submodule strategy

requer GitLab Runner v1.10+.

GIT_SUBMODULE_STRATEGY variável é usada para controlar se / como Gitsubmodules são incluídos quando busca o código antes de uma compilação. Você pode defini-las globalmente ou por trabalho na secção variables.

Existem três valores possíveis: nonenormal e recursive:

• none significa que submódulos não são incluídos quando busca o projectcode. Este é o padrão, que corresponde ao comportamento pré-v1.10.

• normal significa que só estão incluídos os submódulos de nível superior. Ele’sequivalent para:

  git submodule syncgit submodule update --init

• recursive significa que todos os submódulos (incluindo submódulos de submódulos)estão incluídos. Este recurso precisa Git v1. 8. 1 e mais tarde. Ao usar Agitlab Runner com um executor não baseado no Docker, certifique-se de que o Git versionmeets esse requisito. É equivalente a:

  git submodule sync --recursivegit submodule update --init --recursive

para que esse recurso funcione corretamente, o submódulos deve ser configurado(na .gitmodules) com:

• o HTTP(S) URL de um público-repositório acessível, ou
• um caminho relativo para outro repositório, na mesma GitLab servidor. Veja a documentação do submódulos do git.

checkout git

GIT_CHECKOUT variável pode ser usada quando o GIT_STRATEGY está definido paraclone ou fetch para especificar se uma git checkout deve ser executado. Se não for especificado, o padrão é verdadeiro. Você pode configurá-los globalmente ou por trabalho na seçãovariables.

If set tofalse, the runner:

• quando fazer fetch – atualiza o repositório e deixa a cópia de trabalho na atual revisão,
• quando fazer clone – clona o repositório e deixa a cópia de trabalho em thedefault ramo.

If GIT_CHECKOUT is set to true, bothclone and work the same way.O corredor verifica a cópia de trabalho de uma revisão relacionada com o gasoduto IC:

variables: GIT_STRATEGY: clone GIT_CHECKOUT: "false"script: - git checkout -B master origin/master - git merge $CI_COMMIT_SHA

Git limpa os sinalizadores

GIT_CLEAN_FLAGS variável é usada para controlar o comportamento padrão da taggit clean depois de verificar as fontes. Você pode configurá-lo globalmente ou por trabalho na seçãovariables.

GIT_CLEAN_FLAGS aceita todas as opções possíveis do comandogit clean.

git cleanestá desactivado seGIT_CHECKOUT: "false" é especificado.

SeGIT_CLEAN_FLAGS é:

• Não especificado, git clean flags default to -ffdx.
• dado o valor nonegit clean não é executado.

Por exemplo:

variables: GIT_CLEAN_FLAGS: -ffdx -e cache/script: - ls -al cache/

Git fetch extra bandeiras

TheGIT_FETCH_EXTRA_FLAGS variable is used to control the behavior ofgit fetch. Você pode configurá-lo globalmente ou por trabalho na seção variables.

GIT_FETCH_EXTRA_FLAGS aceita todas as opções do comandogit fetch. However, GIT_FETCH_EXTRA_FLAGS flags are appended after the default flags that can’t be modified.

as opções predefinidas são:

• GIT_DEPTH.
• a lista de repspectos.
• um remoto chamado origin.

Se GIT_FETCH_EXTRA_FLAGS é:

• Não especificado, git fetch sinalizadores padrão para --prune --quiet junto com a flag padrão.
• dado o valor nonegit fetch é executado apenas com as opções predefinidas.

Por exemplo, o padrão de sinalizadores são --prune --quiet você pode git fetch mais detalhado, substituindo-se este com apenas --prune:

variables: GIT_FETCH_EXTRA_FLAGS: --prunescript: - ls -al cache/

A configuração acima resulta em git fetch ser chamado desta forma:

git fetch origin $REFSPECS --depth 50 --prune

, Onde $REFSPECS é um valor fornecido para o corredor internamente pelo GitLab.

Clonagem superficial

pode indicar a profundidade de obtenção e clonagem usando GIT_DEPTHGIT_DEPTH faz um clone raso do repositório e pode acelerar significativamente cloning.It pode ser útil para repositórios com um grande número de commits ou binários antigos e grandes. The value ispassed to git fetch and git clone.

In GitLab 12.0 and later, newly-created projects automatically have adefault git depth value of 50.

Se usar uma profundidade de 1 e tiver uma fila de tarefas ou retryjobs, as tarefas poderão falhar.

git fetching and cloning is based on a ref, such as a branch name, so runnerscan’t clone a specific commit SHA. Se vários trabalhos estão na fila, ou você está a refazer um trabalho antigo, o compromisso a ser testado deve estar dentro da história do git que é clonado. Definir um valor demasiado pequeno para GIT_DEPTH pode tornar impossível executar estes commits antigos e unresolved reference é apresentado nos registos de Tarefas. Você deve então reconsiderar mudar GIT_DEPTH para um valor mais elevado.

Empregos que dependem de git describe pode não funcionar corretamente quando GIT_DEPTH isset uma vez que apenas parte do Git história está presente.

para obter ou clonar apenas os últimos 3 commits:

variables: GIT_DEPTH: "3"

Você pode definir globalmente ou por trabalho variables seção.

pastas de compilação personalizadas

por padrão, o GitLab Runner clona o repositório em um subpata único do$CI_BUILDS_DIR diretório. No entanto, o seu projecto pode exigir o código num directório específico (projectos Go, por exemplo). Nesse caso, você pode especificar o GIT_CLONE_PATH variável para dizer ao Executante o diretório para clonar o repositório em:

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/project-nametest: script: - pwd

GIT_CLONE_PATH tem que estar sempre dentro de $CI_BUILDS_DIR. O diretório definido em $CI_BUILDS_DIRé dependente do executor e configuração dos corredores.builds_dirsetting.

isto só pode ser usado quando custom_build_dir está activo na configuração do therunner.Esta é a configuração padrão para o docker e kubernetes executores.

manipular a concorrência

um executor que usa uma concorrência maior que1 pode levar a falhas. Várias tarefas podem estar a trabalhar no mesmo directório se o builds_dirfor partilhado entre tarefas.

o corredor não tenta evitar esta situação. Cabe à administração e aos desenvolvedores cumprir os requisitos da configuração do runner.

Para evitar esse cenário, você pode usar um caminho único dentro de $CI_BUILDS_DIR, porque runnerexposes duas variáveis adicionais que fornecem uma única ID de simultaneidade:

• $CI_CONCURRENT_ID: ID Único para todos os trabalhos a executar dentro de um determinado executor.
• $CI_CONCURRENT_PROJECT_ID: ID único para todas as tarefas em execução dentro do executor e projeto dado.

a configuração mais estável que deve funcionar bem em qualquer cenário e em qualquer executoris para usar $CI_CONCURRENT_IDnoGIT_CLONE_PATH. Por exemplo:

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-nametest: script: - pwd

$CI_CONCURRENT_PROJECT_ID deve ser usado em conjunto com $CI_PROJECT_PATH$CI_PROJECT_PATH fornece um caminho de um repositório. Isto é,group/subgroup/project. Por exemplo:

variables: GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATHtest: script: - pwd

Aninhados caminhos

O valor de GIT_CLONE_PATH é ampliado uma vez e o aninhamento de variableswithin não é suportado.

Por exemplo, você define ambas as variáveis abaixo no seu ficheiro.gitlab-ci.yml :

variables: GOPATH: $CI_BUILDS_DIR/go GIT_CLONE_PATH: $GOPATH/src/namespace/project

O valor de GIT_CLONE_PATH é expandida uma vez no$CI_BUILDS_DIR/go/src/namespace/project, e resulta em failurebecause $CI_BUILDS_DIR não é expandida.

tentativas de fases de trabalho

pode definir o número de tentativas que a tarefa em execução tenta executar as fases seguintes:

O padrão é de uma única tentativa.

Exemplo:

variables: GET_SOURCES_ATTEMPTS: 3

Você pode defini-las globalmente ou por trabalho variables seção.

chamadas de sistema não disponíveis em GitLab.com corredores partilhados

GitLab.com corredores partilhados correm em CoreOS. Isto significa que você não pode usar algumas chamadas do sistema, como getlogin, a partir da biblioteca padrão C.

Artifact and cache settings

as configurações de artefatos e cache controlam a taxa de compressão de artefatos e caches.Use estas configurações para especificar o tamanho do arquivo produzido por uma tarefa.

• em uma rede lenta, uploads podem ser mais rápidos para arquivos menores.
• em uma rede rápida onde largura de banda e armazenamento não são uma preocupação, uploads podem ser mais rápidos usando a taxa de compressão mais rápida, apesar do arquivo produzido ser maior.

para páginas GitLab para servir pedidos de Range, os Artifacts devem usar a configuração ARTIFACT_COMPRESSION_LEVEL: fastest, uma vez que apenas o arquivamento zip não comprimido suporta esta funcionalidade.

Um medidor também pode ser habilitado a fornecer a taxa de transferência para uploads e downloads.

variables: # output upload and download progress every 2 seconds TRANSFER_METER_FREQUENCY: "2s" # Use fast compression for artifacts, resulting in larger archives ARTIFACT_COMPRESSION_LEVEL: "fast" # Use no compression for caches CACHE_COMPRESSION_LEVEL: "fastest"