2018-05-11 10:42:22 +10:00
---
date: "2018-05-10T16:00:00+02:00"
2023-04-06 19:06:32 +10:00
title: "Issue and Pull Request templates"
2018-05-11 10:42:22 +10:00
slug: "issue-pull-request-templates"
2023-07-26 14:53:13 +10:00
sidebar_position: 15
2020-12-09 17:47:06 +11:00
toc: false
2018-05-11 10:42:22 +10:00
draft: false
Refactor docs (#23752)
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.
1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-28 13:33:41 +10:00
aliases:
- /en-us/issue-pull-request-templates
2018-05-11 10:42:22 +10:00
menu:
sidebar:
parent: "usage"
name: "Issue and Pull Request templates"
2023-07-26 14:53:13 +10:00
sidebar_position: 15
2018-05-11 10:42:22 +10:00
identifier: "issue-pull-request-templates"
---
# Issue and Pull Request Templates
2019-03-10 08:15:45 +11:00
Some projects have a standard list of questions that users need to answer
when creating an issue or pull request. Gitea supports adding templates to the
2024-02-21 07:12:47 +11:00
**default branch of the repository** so that they can autopopulate the form when users are
2019-03-10 08:15:45 +11:00
creating issues and pull requests. This will cut down on the initial back and forth
2019-01-29 02:23:59 +11:00
of getting some clarifying details.
2024-02-21 07:12:47 +11:00
It is currently not possible to provide generic issue/pull-request templates globally.
2018-05-11 10:42:22 +10:00
2022-09-02 17:58:49 +10:00
Additionally, the New Issue page URL can be suffixed with `?title=Issue+Title&body=Issue+Text` and the form will be populated with those strings. Those strings will be used instead of the template if there is one.
## File names
2018-05-11 10:42:22 +10:00
Possible file names for issue templates:
2020-12-09 17:47:06 +11:00
- `ISSUE_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `ISSUE_TEMPLATE.yaml`
- `ISSUE_TEMPLATE.yml`
2020-12-09 17:47:06 +11:00
- `issue_template.md`
2022-09-02 17:58:49 +10:00
- `issue_template.yaml`
- `issue_template.yml`
2020-12-09 17:47:06 +11:00
- `.gitea/ISSUE_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `.gitea/ISSUE_TEMPLATE.yaml`
- `.gitea/ISSUE_TEMPLATE.yml`
- `.gitea/issue_template.md`
- `.gitea/issue_template.yaml`
2022-09-09 13:22:33 +10:00
- `.gitea/issue_template.yml`
2020-12-09 17:47:06 +11:00
- `.github/ISSUE_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `.github/ISSUE_TEMPLATE.yaml`
- `.github/ISSUE_TEMPLATE.yml`
2020-12-09 17:47:06 +11:00
- `.github/issue_template.md`
2022-09-02 17:58:49 +10:00
- `.github/issue_template.yaml`
- `.github/issue_template.yml`
2018-05-11 10:42:22 +10:00
2023-03-29 05:22:07 +11:00
Possible file names for issue config:
- `.gitea/ISSUE_TEMPLATE/config.yaml`
- `.gitea/ISSUE_TEMPLATE/config.yml`
- `.gitea/issue_template/config.yaml`
- `.gitea/issue_template/config.yml`
- `.github/ISSUE_TEMPLATE/config.yaml`
- `.github/ISSUE_TEMPLATE/config.yml`
- `.github/issue_template/config.yaml`
- `.github/issue_template/config.yml`
2018-05-11 10:42:22 +10:00
Possible file names for PR templates:
2020-12-09 17:47:06 +11:00
- `PULL_REQUEST_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `PULL_REQUEST_TEMPLATE.yaml`
- `PULL_REQUEST_TEMPLATE.yml`
2020-12-09 17:47:06 +11:00
- `pull_request_template.md`
2022-09-02 17:58:49 +10:00
- `pull_request_template.yaml`
- `pull_request_template.yml`
2020-12-09 17:47:06 +11:00
- `.gitea/PULL_REQUEST_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `.gitea/PULL_REQUEST_TEMPLATE.yaml`
- `.gitea/PULL_REQUEST_TEMPLATE.yml`
2020-12-09 17:47:06 +11:00
- `.gitea/pull_request_template.md`
2022-09-02 17:58:49 +10:00
- `.gitea/pull_request_template.yaml`
- `.gitea/pull_request_template.yml`
2020-12-09 17:47:06 +11:00
- `.github/PULL_REQUEST_TEMPLATE.md`
2022-09-02 17:58:49 +10:00
- `.github/PULL_REQUEST_TEMPLATE.yaml`
- `.github/PULL_REQUEST_TEMPLATE.yml`
2020-12-09 17:47:06 +11:00
- `.github/pull_request_template.md`
2022-09-02 17:58:49 +10:00
- `.github/pull_request_template.yaml`
- `.github/pull_request_template.yml`
2019-01-29 02:23:59 +11:00
2022-09-02 17:58:49 +10:00
## Directory names
2020-09-12 00:48:39 +10:00
2020-11-28 17:12:22 +11:00
Alternatively, users can create multiple issue templates inside a special directory and allow users to choose one that more specifically
2020-09-12 00:48:39 +10:00
addresses their problem.
Possible directory names for issue templates:
2020-12-09 17:47:06 +11:00
- `ISSUE_TEMPLATE`
- `issue_template`
- `.gitea/ISSUE_TEMPLATE`
- `.gitea/issue_template`
- `.github/ISSUE_TEMPLATE`
- `.github/issue_template`
- `.gitlab/ISSUE_TEMPLATE`
- `.gitlab/issue_template`
2020-09-12 00:48:39 +10:00
2022-09-02 17:58:49 +10:00
Inside the directory can be multiple markdown (`.md`) or yaml (`.yaml`/`.yml`) issue templates of the form.
## Syntax for markdown template
2020-09-12 00:48:39 +10:00
2020-12-09 17:47:06 +11:00
```md
---
2020-09-12 00:48:39 +10:00
name: "Template Name"
about: "This template is for testing!"
title: "[TEST] "
2021-12-18 08:29:09 +11:00
ref: "main"
2020-09-12 00:48:39 +10:00
labels:
2020-12-09 17:47:06 +11:00
- bug
- "help needed"
---
2020-09-12 00:48:39 +10:00
This is the template!
```
In the above example, when a user is presented with the list of issues they can submit, this would show as `Template Name` with the description
2020-11-28 17:12:22 +11:00
`This template is for testing!` . When submitting an issue with the above example, the issue title would be pre-populated with
2020-09-12 00:48:39 +10:00
`[TEST] ` while the issue body would be pre-populated with `This is the template!` . The issue would also be assigned two labels,
2021-12-18 08:29:09 +11:00
`bug` and `help needed` , and the issue will have a reference to `main` .
2022-09-02 17:58:49 +10:00
## Syntax for yaml template
This example YAML configuration file defines an issue form using several inputs to report a bug.
```yaml
name: Bug Report
about: File a bug report
title: "[Bug]: "
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
```
### Markdown
You can use a `markdown` element to display Markdown in your form that provides extra context to the user, but is not submitted.
Attributes:
| Key | Description | Required | Type | Default | Valid values |
|-------|--------------------------------------------------------------|----------|--------|---------|--------------|
| value | The text that is rendered. Markdown formatting is supported. | Required | String | - | - |
### Textarea
You can use a `textarea` element to add a multi-line text field to your form. Contributors can also attach files in `textarea` fields.
Attributes:
| Key | Description | Required | Type | Default | Valid values |
|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|--------|--------------|---------------------------|
| label | A brief description of the expected user input, which is also displayed in the form. | Required | String | - | - |
| description | A description of the text area to provide context or guidance, which is displayed in the form. | Optional | String | Empty String | - |
| placeholder | A semi-opaque placeholder that renders in the text area when empty. | Optional | String | Empty String | - |
| value | Text that is pre-filled in the text area. | Optional | String | - | - |
| render | If a value is provided, submitted text will be formatted into a codeblock. When this key is provided, the text area will not expand for file attachments or Markdown editing. | Optional | String | - | Languages known to Gitea. |
Validations:
| Key | Description | Required | Type | Default | Valid values |
|----------|------------------------------------------------------|----------|---------|---------|--------------|
| required | Prevents form submission until element is completed. | Optional | Boolean | false | - |
### Input
You can use an `input` element to add a single-line text field to your form.
Attributes:
| Key | Description | Required | Type | Default | Valid values |
|-------------|--------------------------------------------------------------------------------------------|----------|--------|--------------|--------------|
| label | A brief description of the expected user input, which is also displayed in the form. | Required | String | - | - |
| description | A description of the field to provide context or guidance, which is displayed in the form. | Optional | String | Empty String | - |
| placeholder | A semi-transparent placeholder that renders in the field when empty. | Optional | String | Empty String | - |
| value | Text that is pre-filled in the field. | Optional | String | - | - |
Validations:
| Key | Description | Required | Type | Default | Valid values |
|-----------|--------------------------------------------------------------------------------------------------|----------|---------|---------|--------------------------------------------------------------------------|
| required | Prevents form submission until element is completed. | Optional | Boolean | false | - |
| is_number | Prevents form submission until element is filled with a number. | Optional | Boolean | false | - |
| regex | Prevents form submission until element is filled with a value that match the regular expression. | Optional | String | - | a [regular expression ](https://en.wikipedia.org/wiki/Regular_expression ) |
### Dropdown
You can use a `dropdown` element to add a dropdown menu in your form.
Attributes:
| Key | Description | Required | Type | Default | Valid values |
|-------------|-----------------------------------------------------------------------------------------------------|----------|--------------|--------------|--------------|
| label | A brief description of the expected user input, which is displayed in the form. | Required | String | - | - |
| description | A description of the dropdown to provide extra context or guidance, which is displayed in the form. | Optional | String | Empty String | - |
| multiple | Determines if the user can select more than one option. | Optional | Boolean | false | - |
| options | An array of options the user can choose from. Cannot be empty and all choices must be distinct. | Required | String array | - | - |
Validations:
| Key | Description | Required | Type | Default | Valid values |
|----------|------------------------------------------------------|----------|---------|---------|--------------|
| required | Prevents form submission until element is completed. | Optional | Boolean | false | - |
### Checkboxes
You can use the `checkboxes` element to add a set of checkboxes to your form.
Attributes:
| Key | Description | Required | Type | Default | Valid values |
|-------------|-------------------------------------------------------------------------------------------------------|----------|--------|--------------|--------------|
| label | A brief description of the expected user input, which is displayed in the form. | Required | String | - | - |
| description | A description of the set of checkboxes, which is displayed in the form. Supports Markdown formatting. | Optional | String | Empty String | - |
| options | An array of checkboxes that the user can select. For syntax, see below. | Required | Array | - | - |
For each value in the options array, you can set the following keys.
| Key | Description | Required | Type | Default | Options |
|----------|------------------------------------------------------------------------------------------------------------------------------------------|----------|---------|---------|---------|
| label | The identifier for the option, which is displayed in the form. Markdown is supported for bold or italic text formatting, and hyperlinks. | Required | String | - | - |
| required | Prevents form submission until element is completed. | Optional | Boolean | false | - |
2023-03-29 05:22:07 +11:00
## Syntax for issue config
This is a example for a issue config file
```yaml
blank_issues_enabled: true
contact_links:
- name: Gitea
url: https://gitea.io
about: Visit the Gitea Website
```
### Possible Options
| Key | Description | Type | Default |
|----------------------|-------------------------------------------------------------------------------------------------------|--------------------|----------------|
| blank_issues_enabled | If set to false, the User is forced to use a Template | Boolean | true |
| contact_links | Custom Links to show in the Choose Box | Contact Link Array | Empty Array |
### Contact Link
| Key | Description | Type | Required |
|----------------------|-------------------------------------------------------------------------------------------------------|---------|----------|
| name | the name of your link | String | true |
| url | The URL of your Link | String | true |
| about | A short description of your Link | String | true |
