Download gitlab - download do código-fonte gitlab

gitlab

Outro código-fonte

v13.2.1

Baixar

@semantic-release/gitlab

Plugin de liberação semântica para publicar uma versão do GitLab.

Etapa	Descrição
`verifyConditions`	Verifique a presença e a validade da autenticação (definida através de variáveis de ambiente).
`publish`	Publique uma versão do GitLab.
`success`	Adicione um comentário a cada problema do GitLab ou solicitação de mesclagem resolvida pelo lançamento.
`fail`	Abra ou atualize um problema do GitLab com informações sobre os erros que causaram a falha do lançamento.

Instalar

$ npm install @semantic-release/gitlab -D

Uso

O plugin pode ser configurado no arquivo de configuração de liberação semântica :

{
  "branches" : [ " main " ],
  "plugins" : [
    " @semantic-release/commit-analyzer " ,
    " @semantic-release/release-notes-generator " ,
    [
      " @semantic-release/gitlab " ,
      {
        "gitlabUrl" : " https://custom.gitlab.com " ,
        "assets" : [
          { "path" : " dist/asset.min.css " , "label" : " CSS distribution " },
          { "path" : " dist/asset.min.js " , "label" : " JS distribution " , "target" : " generic_package " },
          { "path" : " dist/asset.min.js " , "label" : " v${nextRelease.version}.js " },
          { "url" : " https://gitlab.com/gitlab-org/gitlab/-/blob/master/README.md " }
        ]
      }
    ]
  ]
}

Com este exemplo, as versões do GitLab serão publicadas na instância https://custom.gitlab.com .

Configuração

Autenticação GitLab

A configuração de autenticação do GitLab é necessária e pode ser definida por meio de variáveis de ambiente.

Crie um token de acesso de projeto, token de acesso de grupo ou token de acesso pessoal com função Desenvolvedor (ou superior) e o escopo api e disponibilize-o em seu ambiente de CI por meio da variável de ambiente GL_TOKEN . Se você estiver usando GL_TOKEN como autenticação de repositório Git remoto, ele também deverá ter o escopo write_repository .

Nota : Ao executar com dryRun apenas o escopo read_repository é necessário.

Variáveis de ambiente

Variável	Descrição
`GL_TOKEN` ou `GITLAB_TOKEN`	Obrigatório. O token usado para autenticação no GitLab.
`GL_URL` ou `GITLAB_URL`	O ponto final do GitLab.
`GL_PREFIX` ou `GITLAB_PREFIX`	O prefixo da API GitLab.
`HTTP_PROXY` ou `HTTPS_PROXY`	Proxy HTTP ou HTTPS a ser usado.
`NO_PROXY`	Padrões para os quais o proxy deve ser ignorado. Veja detalhes abaixo.

Configuração de proxy

O plugin suporta a passagem de solicitações por meio de um servidor proxy.

Você pode configurar um servidor proxy por meio da variável de ambiente HTTPS_PROXY : HTTPS_PROXY=http://proxyurl.com:8080

Se o seu servidor proxy exigir autenticação, insira o nome de usuário e a senha na URL: HTTPS_PROXY=http://user:[email protected]:8080

Se sua instância do GitLab for exposta via HTTP simples (não recomendado!), Use HTTP_PROXY .

Se você precisar ignorar o proxy para alguns hosts, configure a variável de ambiente NO_PROXY : NO_PROXY=*.host.com, host.com

Opções

Opção	Descrição	Padrão
`gitlabUrl`	O ponto final do GitLab.	Variável de ambiente `GL_URL` ou `GITLAB_URL` ou variáveis de ambiente fornecidas pelo CI se estiver em execução no GitLab CI/CD ou `https://gitlab.com` .
`gitlabApiPathPrefix`	O prefixo da API GitLab.	Variável de ambiente `GL_PREFIX` ou `GITLAB_PREFIX` ou variáveis de ambiente fornecidas pelo CI se estiver em execução no GitLab CI/CD ou `/api/v4` .
`assets`	Uma matriz de arquivos para upload para o lançamento. Veja ativos.	-
`milestones`	Uma série de títulos de marcos para associar ao lançamento. Consulte API de lançamento do GitLab.	-
`successComment`	O comentário a ser adicionado a cada problema e solicitação de mesclagem resolvidos pela versão. Veja sucessoComentário.	? Este problema foi resolvido na versão ${nextRelease.version} ?nnO lançamento está disponível no GitLab
`successCommentCondition`	Use isso como condição para comentar problemas ou solicitações de mesclagem. Consulte SuccessCommentCondition.	-
`failComment`	O conteúdo do problema criado quando uma versão falha. Veja failComment.	Mensagem amigável com links para documentação e suporte de lançamento semântico , com a lista de erros que causaram a falha do lançamento.
`failTitle`	O título do problema criado quando uma versão falha.	`The automated release is failing`
`failCommentCondition`	Use isso como condição para comentar ou criar problemas em caso de falhas. Consulte failCommentCondition.	-
`labels`	Os rótulos a serem adicionados ao problema criado quando uma versão falha. Defina como `false` para não adicionar nenhum rótulo. Os rótulos devem ser separados por vírgulas conforme descrito nos documentos oficiais, por exemplo, `"semantic-release,bot"` .	`semantic-release`
`assignee`	O responsável a ser adicionado ao problema criado quando uma versão falha.	-

ativos

Pode ser um glob ou Array de globs e Object s com as seguintes propriedades:

Propriedade	Descrição	Padrão
`path`	Obrigatório , a menos que `url` esteja definido. Um globo para identificar os arquivos a serem carregados. Suporta modelos Lodash.	-
`url`	Alternativa para definir `path` isso fornece a capacidade de adicionar links para lançamentos, por exemplo, URLs para imagens de contêiner. Suporta modelos Lodash.	-
`label`	Breve descrição do arquivo exibido na versão do GitLab. Ignorado se `path` corresponder a mais de um arquivo. Suporta modelos Lodash.	Nome do arquivo extraído do `path` .
`type`	Tipo de ativo exibido na versão do GitLab. Pode ser `runbook` , `package` , `image` e `other` (veja documentos oficiais sobre ativos de lançamento). Suporta modelos Lodash.	`other`
`filepath`	Um caminho de arquivo para criar um link permanente apontando para o ativo (requer GitLab 12.9+, consulte os documentos oficiais sobre links permanentes). Ignorado se `path` corresponder a mais de um arquivo. Suporta modelos Lodash.	-
`target`	Controla para onde o arquivo é carregado. Pode ser definido como `project_upload` para armazenar o arquivo como upload de projeto ou `generic_package` para armazenar o arquivo como pacote genérico.	`project_upload`
`status`	Isso só é aplicado se `target` estiver definido como `generic_package` . O status genérico do pacote. Pode ser `default` e `hidden` (ver documentos oficiais sobre pacotes genéricos).	`default`

Cada entrada na Array assets é agrupada individualmente. Um glob pode ser uma String ( "dist/**/*.js" ou "dist/mylib.js" ) ou um Array de String s que serão agrupados ( ["dist/**", "!**/*.css"] ).

Se um diretório for configurado, todos os arquivos desse diretório e seus filhos serão incluídos.

Nota : Se um arquivo tiver uma correspondência em assets ele será incluído mesmo que também tenha uma correspondência em .gitignore .

exemplos de ativos

'dist/*.js' : inclui todos os arquivos js no diretório dist , mas não em seus subdiretórios.

[['dist', '!**/*.css']] : inclui todos os arquivos no diretório dist e seus subdiretórios, excluindo os arquivos css .

[{path: 'dist/MyLibrary.js', label: 'MyLibrary JS distribution'}, {path: 'dist/MyLibrary.css', label: 'MyLibrary CSS distribution'}] : inclui dist/MyLibrary.js e dist/MyLibrary.css e rotule-os MyLibrary JS distribution e MyLibrary CSS distribution na versão GitLab.

[['dist/**/*.{js,css}', '!**/*.min.*'], {path: 'build/MyLibrary.zip', label: 'MyLibrary'}] : incluir todos os arquivos js e css no diretório dist e seus subdiretórios, excluindo a versão minificada, mais o arquivo build/MyLibrary.zip e rotule-o como MyLibrary na versão do GitLab.

sucessoComment

A mensagem para os comentários do problema é gerada com o modelo Lodash. As seguintes variáveis estão disponíveis:

Parâmetro	Descrição
`branch`	`Object` com propriedades `name` , `type` , `channel` , `range` e `prerelease` do branch a partir do qual o lançamento é feito.
`lastRelease`	`Object` com `version` , `channel` , `gitTag` e `gitHead` do último release.
`nextRelease`	`Object` com `version` , `channel` , `gitTag` , `gitHead` e `notes` do release que está sendo feito.
`commits`	`Array` de commit `Object` s com `hash` , `subject` , `body` `message` e `author` .
`releases`	`Array` com release `Object` s para cada release publicado, com dados de release opcionais como `name` e `url` .
`issue`	Um objeto GitLab API Issue no qual o comentário será postado ou `false` ao comentar solicitações de mesclagem.
`mergeRequest`	Um objeto de solicitação de mesclagem da API GitLab no qual o comentário será postado ou `false` ao comentar problemas.

sucessoCommentCondição

A condição de comentário de sucesso é gerada com o modelo Lodash. As seguintes variáveis estão disponíveis:

Parâmetro	Descrição
`branch`	`Object` com propriedades `name` , `type` , `channel` , `range` e `prerelease` do branch a partir do qual o lançamento é feito.
`lastRelease`	`Object` com `version` , `channel` , `gitTag` e `gitHead` do último release.
`nextRelease`	`Object` com `version` , `channel` , `gitTag` , `gitHead` e `notes` do release que está sendo feito.
`commits`	`Array` de commit `Object` s com `hash` , `subject` , `body` `message` e `author` .
`releases`	`Array` com release `Object` s para cada release publicado, com dados de release opcionais como `name` e `url` .
`issue`	Um objeto GitLab API Issue no qual o comentário será postado.
`mergeRequest`	Um objeto de solicitação de mesclagem da API GitLab no qual o comentário será postado.

exemplo de sucessoCommentCondition

não crie nenhum comentário: defina como false ou modelo: "<% return false; %>"
para comentar apenas os problemas: "<% return issue %>"
para comentar apenas em solicitações de mesclagem: "<% return mergeRequest %>"
você pode usar rótulos para filtrar problemas: "<% return issue.labels?.includes('semantic-release-relevant') %>"

verifique o objeto GitLab API Merge Request ou o objeto GitLab API Issue para propriedades que podem ser usadas para o filtro

falhaComment

A mensagem para o conteúdo do problema é gerada com o modelo Lodash. As seguintes variáveis estão disponíveis:

Parâmetro	Descrição
`branch`	O branch do qual o lançamento falhou.
`errors`	Uma `Array` de SemanticReleaseError. Cada erro possui as propriedades `message` , `code` , `pluginName` `details` . `pluginName` contém o nome do pacote do plugin que gerou o erro. `details` contém informações sobre o erro formatado em markdown.

exemplo de failComment

O failComment This release from branch ${branch.name} had failed due to the following errors:n- ${errors.map(err => err.message).join('\n- ')} irá gerar o comentário:

Esta versão do branch master falhou devido aos seguintes erros:
Mensagem de erro 1
Mensagem de erro 2

failCommentCondição

A condição de comentário de falha é gerada com o modelo Lodash. As seguintes variáveis estão disponíveis:

Parâmetro	Descrição
`branch`	`Object` com propriedades `name` , `type` , `channel` , `range` e `prerelease` do branch a partir do qual o lançamento é feito.
`lastRelease`	`Object` com `version` , `channel` , `gitTag` e `gitHead` do último release.
`nextRelease`	`Object` com `version` , `channel` , `gitTag` , `gitHead` e `notes` do release que está sendo feito.
`commits`	`Array` de commit `Object` s com `hash` , `subject` , `body` `message` e `author` .
`releases`	`Array` com release `Object` s para cada release publicado, com dados de release opcionais como `name` e `url` .
`issue`	Um objeto Issue da API GitLab no qual o comentário será postado - disponível apenas se existir um problema aberto.

Exemplo de failCommentCondition

não crie nenhum comentário: defina como false ou modelo: "<% return false; %>"
para comentar apenas no branch principal: "<% return branch.name === 'main' %>"
você pode usar rótulos para filtrar problemas, ou seja, para não comentar se o problema estiver rotulado com wip : "<% return !issue.labels?.includes('wip') %>"

verifique o objeto GitLab API Issue para propriedades que podem ser usadas para o filtro

Compatibilidade

A versão mais recente deste plugin é compatível com todas as versões atualmente suportadas do GitLab, que é a versão principal atual e as duas versões principais anteriores. Não há garantia de que este plugin funcione com versões não suportadas do GitLab.

Quebrando mudanças em 14.0

Se você estiver usando GitLab.com ou atualizou sua instância auto-hospedada do GitLab para 14.0, use a versão >=6.0.7 deste plugin.

Por que?

No GitLab 14.0, a criação de uma versão usando a API Tags foi removida (consulte # 290311). Este plugin foi atualizado para usar a API Releases em #184, que está disponível na versão 6.0.7 e posteriores.

Expandir

Informações adicionais