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
-
Em GitHub, acesse a página principal do repositório.
-
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.
-
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.
-
Use o menu suspenso Adicionar modelo e clique no tipo de modelo que deseja criar.
-
Para visualizar ou editar o modelo antes de fazer commit dele no repositório, ao lado do modelo, clique em Visualizar e editar.
-
Para editar o modelo, clique em e digite os campos para editar o conteúdo.
-
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
ouassignees
em um formato de frontmatter YAML. -
Quando terminar de editar e visualizar o modelo, clique em Propor alterações no canto superior direito da página.
-
No campo "Mensagem de commit", digite uma mensagem de commit que descreva as alterações.
-
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".
-
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
Nota: formulários de problemas estão atualmente em 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.
name: Bug Report description: File a bug report. title: "[Bug]: " labels: ["bug", "triage"] projects: ["octo-org/1", "octo-org/44"] 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) default: 0 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
name: Bug Report
description: File a bug report.
title: "[Bug]: "
labels: ["bug", "triage"]
projects: ["octo-org/1", "octo-org/44"]
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)
default: 0
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.
- 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".
- No repositório, crie um arquivo chamado
.github/ISSUE_TEMPLATE/FORM-NAME.yml
, substituindoFORM-NAME
pelo nome do formulário de problema. Para obter mais informações sobre como criar arquivos no GitHub, confira "Criar arquivos". - 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".
- 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.
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.
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.
-
Em GitHub, acesse a página principal do repositório.
-
Acima da lista de arquivos, selecione o menu suspenso Adicionar arquivo e clique em Criar arquivo.
Como alternativa, é possível clicar em na exibição em árvore de arquivos à esquerda.
-
No campo de nome do arquivo, digite
.github/ISSUE_TEMPLATE/config.yml
. -
No corpo do novo arquivo, digite o conteúdo do seu arquivo de configuração.
-
Clique em Fazer commit das alterações...
-
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".
-
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".
-
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
.