Esta versão do GitHub Enterprise Server foi descontinuada em 2024-07-09. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Configurando modelos de problemas em seu repositório

Você pode personalizar os modelos disponíveis para os contribuidores usarem quando abrirem novos problemas no seu repositório.

Neste artigo

Você pode criar modelos de problemas padrão e um arquivo de configuração padrão para modelos de problemas para sua organização ou conta pessoal. Para obter mais informações, confira "Como criar um arquivo padrão de integridade da comunidade".

Criando modelos de problemas

  1. No sua instância do GitHub Enterprise Server, navegue até a página principal do repositório.

  2. Abaixo do nome do repositório, clique em Configurações. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela de um cabeçalho de repositório que mostra as guias. A guia "Configurações" é realçada por um contorno laranja-escuro.

  3. Na seção "Recursos", em Problemas, clique em Configurar modelos. Talvez seja necessário habilitar Problemas e atualizar a página para você ver o botão.

Captura de tela da seção "Recursos" das configurações de um repositório com a configuração "Problemas" marcada e o botão verde "Configurar modelos" visível.

  1. Use o menu suspenso Adicionar modelo e clique no tipo de modelo que deseja criar.

    Captura de tela do menu suspenso "Adicionar modelo" expandido para mostrar os modelos padrão "Relatório de bugs" e "Solicitação de recursos". Além disso, o "Modelo personalizado" está listado.

  2. Para visualizar ou editar o modelo antes de fazer commit dele no repositório, ao lado do modelo, clique em Visualizar e editar.

  3. Para editar o modelo, clique em e digite os campos para editar o conteúdo.

    Captura de tela da visualização de um modelo de problema. À direita do nome do modelo, um ícone de lápis está contornado em laranja escuro.

  4. Para definir automaticamente um título de problema padrão, atribua o problema a pessoas com acesso de leitura ao repositório ou aplique rótulos aos problemas levantados por meio do modelo usando os campos em "Informações adicionais opcionais". Adicione também esses detalhes no modelo de problema com title, labels ou assignees em um formato de frontmatter YAML.

  5. Quando terminar de editar e visualizar o modelo, clique em Propor alterações no canto superior direito da página.

  6. No campo "Mensagem de commit", digite uma mensagem de commit que descreva as alterações.

  7. Abaixo dos campos de mensagem do commit, selecione se vai fazer commit do modelo diretamente no branch padrão ou se vai criar um branch e abrir uma solicitação de pull. Para obter mais informações sobre as solicitações de pull, confira "Sobre solicitação de pull".

  8. Clique em Fazer commit das alterações. Assim que essas alterações passarem por merge no branch padrão, o modelo será disponibilizado para os contribuidores usarem quando abrirem novos problemas no repositório.

Criando formulários de problema

Observação: os formulários de problemas estão atualmente em versão beta e sujeitos a alterações.

Com formulários de problemas, é possível criar modelos de problemas com campos personalizáveis de formulário web. É possível incentivar os contribuidores a incluir informações específicas e estruturadas usando formulários de problemas no seu repositório. Os formulários de problemas são escritos em YAML usando o esquema de formulário de GitHub. Para obter mais informações, confira "Sintaxe para o esquema de formulário do GitHub". Se você não estiver familiarizado com o YAML e quiser saber mais, confira "Aprenda a usar o YAML em Y minutos".

Para usar um formulário de problema no seu repositório, você precisa criar um arquivo e adicioná-lo à pasta .github/ISSUE_TEMPLATE no seu repositório.

Aqui está um exemplo de um arquivo de configuração do formulário de problema.

YAML
name: Bug Report
description: File a bug report.
title: "[Bug]: "
labels: ["bug", "triage"]
assignees:
  - octocat
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: input
    id: contact
    attributes:
      label: Contact Details
      description: How can we get in touch with you if we need more info?
      placeholder: ex. email@example.com
    validations:
      required: false
  - type: textarea
    id: what-happened
    attributes:
      label: What happened?
      description: Also tell us, what did you expect to happen?
      placeholder: Tell us what you see!
      value: "A bug happened!"
    validations:
      required: true
  - type: dropdown
    id: version
    attributes:
      label: Version
      description: What version of our software are you running?
      options:
        - 1.0.2 (Default)
        - 1.0.3 (Edge)
    validations:
      required: true
  - type: dropdown
    id: browsers
    attributes:
      label: What browsers are you seeing the problem on?
      multiple: true
      options:
        - Firefox
        - Chrome
        - Safari
        - Microsoft Edge
  - type: textarea
    id: logs
    attributes:
      label: Relevant log output
      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
      render: shell
  - type: checkboxes
    id: terms
    attributes:
      label: Code of Conduct
      description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com). 
      options:
        - label: I agree to follow this project's Code of Conduct
          required: true

Aqui está a versão renderizada do formulário de problema.

Captura de tela de um formulário de problema renderizado, com uma combinação de campos de texto e menus suspensos.

  1. Escolha um repositório em que você deseja criar um formulário de problema. Você pode usar um repositório existente ao qual você tem acesso de gravação ou criar um novo repositório. Para obter mais informações sobre como criar um repositório, confira "Criar um repositório".
  2. No repositório, crie um arquivo chamado .github/ISSUE_TEMPLATE/FORM-NAME.yml, substituindo FORM-NAME pelo nome do formulário de problema. Para obter mais informações sobre como criar arquivos no GitHub, confira "Criar arquivos".
  3. No texto do novo arquivo, digite o conteúdo do formulário de seu problema. Para obter mais informações, confira "Sintaxe para formulários de problema".
  4. Faça o commit do seu arquivo para o branch padrão do seu repositório. Para obter mais informações, confira "Criar arquivos".

Configurando o seletor de modelos

Você pode personalizar o seletor de modelo de problema que as pessoas veem ao criar um problema no seu repositório adicionando um arquivo config.yml à pasta .github/ISSUE_TEMPLATE.

Você pode incentivar os colaboradores a usar modelos de problema definindo blank_issues_enabled como false. Se você definir blank_issues_enabled como true, as pessoas terão a opção de abrir um problema em branco.

Observação: se você usou o fluxo de trabalho herdado para criar manualmente um arquivo issue_template.md na pasta .github e habilitar problemas em branco no arquivo config.yml, o modelo em issue_template.md será usado quando as pessoas optarem por abrir um problema em branco. Se você desativar problemas em branco, o modelo nunca será usado.

Se preferir receber determinados relatórios fora do GitHub Enterprise Server, você poderá direcionar as pessoas para sites externos com contact_links.

Este é um exemplo de arquivo config.yml.

YAML
blank_issues_enabled: false
contact_links:
  - name: GitHub Community Support
    url: https://github.com/orgs/community/discussions
    about: Please ask and answer questions here.
  - name: GitHub Security Bug Bounty
    url: https://bounty.github.com/
    about: Please report security vulnerabilities here.

Seu arquivo de configuração customizará o seletor de modelos quando o arquivo for mesclado ao branch padrão do repositório.

  1. No sua instância do GitHub Enterprise Server, navegue até a página principal do repositório.

  2. Acima da lista de arquivos, usando o menu suspenso Adicionar arquivo, clique em Criar arquivo.

  3. No campo de nome do arquivo, digite .github/ISSUE_TEMPLATE/config.yml.

  4. No corpo do novo arquivo, digite o conteúdo do seu arquivo de configuração.

  5. No campo "Mensagem do commit", digite uma mensagem curta e relevante que descreva a alteração que você fez no arquivo. Você pode atribuir o commit a mais de um autor na mensagem de commit. Para obter mais informações, confira "Criar um commit com vários autores".

  6. Abaixo dos campos de mensagem do commit, opte por adicionar o commit ao branch atual ou a um novo branch. Se seu branch atual for o branch-padrão, você deverá optar por criar um novo branch para seu commit e, em seguida, criar um pull request. Para obter mais informações, confira "Como criar uma solicitação de pull".

    Captura de tela de uma solicitação de pull GitHub mostrando um botão de opção para confirmar diretamente no branch principal ou para criar um branch. O novo branch está selecionado.

  7. Clique em Fazer commit de alterações ou em Propor alterações.

Alterações na ordem dos modelos

É possível definir a ordem em que os modelos de problemas aparecerão no seletor de modelos ao fazer alterações nos nomes dos arquivos de modelos. Os modelos em .github/ISSUE_TEMPLATE são listados de modo alfanumérico e agrupados por tipo de arquivo, com os arquivos YAML aparecendo antes dos arquivos Markdown.

Para controlar a ordem dos modelos, prefixe os nomes dos arquivos com um número. Por exemplo: 1-bug.yml, 2-feature-request.yml e 3-epic.yml.

Se houver dez ou mais modelos, a ordem alfanumérica faz com que 11-bug.yml seja posicionado entre 1-feature.yml e 2-support.yml. É possível manter a ordem pretendida ao prefixar os nomes dos arquivos numéricos com um 0 adicional. Por exemplo: 01-feature.yml, 02-support.yml e 11-bug.yml.

Leitura adicional