Github как сообщить об ошибке

See JWilliams’ answer for where to report bugs to GitHub. [Edit: perhaps this should be an answer to your other question.]

For what it’s worth, it’s not a good idea to use anything other than UTF-8 for the author and committer name encoding—the encoding field of the header is too difficult to apply to the pre-body part of the header, since it comes at the end of the lines:

>>> import subprocess
>>> p = subprocess.Popen(['git', 'cat-file', '-p', 'HEAD'], stdout=subprocess.PIPE)
>>> o = p.stdout.read()
>>> hdr, body = o.split('nn', 1)
>>> hdr = hdr.splitlines()

The header lines are long, even after splitting:

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author xc5x99x89x83@xc8x96x97x97x85x99 <x88x96x97x97x85x99|x96x94x95x89x86x81x99x89x96xa4xa2Kx96x99x87> 1528844508 -0700',
 'committer xc5x99x89x83@xc8x96x97x97x85x99 <x88x96x97x97x85x99|x96x94x95x89x86x81x99x89x96xa4xa2Kx96x99x87> 1528844508 -0700',
 'encoding cp037']

but we can see that the encoding comes last. If the encoding were something that had byte-codes that resembled newlines (cp037 doesn’t, fortunately) we would not be able to parse the header itself.

For the body, however, it’s a good idea to use the header’s encoding information. If we work in something that does have the encoding available, well:

>>> body.decode('cp037')
u'Well, this should be interesting.x8e'

(Python 2.7 here of course).

Obviously neither GitHub nor my Git on this machine can do this for cp037, but on this particular host, that’s not surprising:

$ iconv -f cp037
iconv: conversion from cp037 unsupported

On another machine that has the character set installed, iconv does work. I did not try this commit in Git there, but I did feed a header-line byte string through it; the result was:

>>> import subprocess
>>> p = subprocess.Popen(['iconv', '-f', 'cp037'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
>>> so, se = p.communicate(s)
>>> so
'Eric Hopperxc2x80x14hopper@omnifarious.orgxc2x9e'

As you can see, the angle brackets have been damaged in translation (because the parse here was overly simple—we’d have to carefully avoid translating them). Again, though, the hazards are obvious: what if the encoding produces >?

Проблемы можно создавать различными способами, поэтому вы можете выбрать наиболее удобный метод для рабочего процесса.

С помощью проблем можно отслеживать ошибки, улучшения и другие запросы. Дополнительные сведения см. в разделе О проблемах.

Администраторы репозитория могут отключать проблемы для репозитория. Дополнительные сведения см. в разделе Отключение проблем.

Создание проблемы из репозитория

1. На GitHub.com перейдите на главную страницу репозитория. 1. Под именем репозитория щелкните Проблемы.

   1. Щелкните Новая проблема.
   

2. Если в репозитории используются шаблоны проблем, рядом с типом проблемы, которую вы хотите открыть, нажмите кнопку Начало работы.

   Если тип проблемы, который вы хотите открыть, не включен в доступные параметры, нажмите кнопку Открыть пустую проблему.

   

3. В поле «Название» введите название проблемы.

4. В поле текста комментария введите описание проблемы. 1. Если вы являетесь координатором проекта, вы можете назначить проблему другому пользователю, добавить ее на панель проекта, связать ее с вехой или применить метку. 1. Закончив, нажмите кнопку Отправить новую проблему.

Создание проблемы с помощью GitHub CLI

GitHub CLI — это инструмент с открытым исходным кодом для использования GitHub из командной строки компьютера. При работе с командной строкой можно использовать GitHub CLI — это позволит экономить время и не переключать контекст. Дополнительные сведения о GitHub CLI см. в разделе Сведения о GitHub CLI.

Чтобы создать проблему, используйте подкоманду gh issue create. Чтобы пропустить интерактивные подсказки, включите флаги --body и --title.

gh issue create --title "My new issue" --body "Here are more details."

Также можно указать уполномоченных пользователей, метки, вехи и проекты.

gh issue create --title "My new issue" --body "Here are more details." --assignee @me,monalisa --label "bug,help wanted" --project onboarding --milestone "learning codebase"

Новую проблему можно создать из комментария в существующей проблеме или запросе на вытягивание. При создании проблемы из комментария она будет содержать фрагмент, отображающий комментарий в исходном расположении.

1. Перейдите к комментарию, из которого хотите создать проблему.

2. В этом комментарии щелкните .

   

3. Щелкните Создать ссылку в новой проблеме.

4. Используйте раскрывающееся меню «Репозиторий» и выберите репозиторий, в который вы хотите открыть проблему.

5. Введите содержательное название и текст проблемы.

6. Щелкните Создать проблему.

7. Если вы являетесь координатором проекта, вы можете назначить проблему другому пользователю, добавить ее на панель проекта, связать ее с вехой или применить метку. 1. Закончив, нажмите кнопку Отправить новую проблему.

Создание проблемы из кода

Новую проблему можно создать из конкретной строки или нескольких строк кода в файле или запросе на вытягивание. При создании проблемы из кода она будет содержать фрагмент, отображающий выбранную строку или диапазон кода. Создать такую проблему можно только в том репозитории, в котором хранится код.

1. На GitHub.com перейдите на главную страницу репозитория.

2. Найдите код, на который хотите сослаться в проблеме:

   • Чтобы создать проблему по коду из файла, откройте этот файл.
   • Чтобы открыть проблему с кодом в запросе на вытягивание, перейдите к запросу на вытягивание и щелкните Файлы изменены. Затем откройте файл, содержащий код, который необходимо включить в комментарий, и щелкните Просмотреть.

3. Выберите, следует ли выбрать одну строку или диапазон.

   • Для выбора одной строки кода, щелкните номер строки, чтобы выделить ее.
   • Для выбора диапазона щелкните номер первой строки диапазона, чтобы выделить ее. Затем наведите указатель мыши на последнюю строку диапазона кода, нажмите клавишу SHIFT и щелкните номер строки, чтобы выбрать весь диапазон.

4. Слева от диапазона кода щелкните . В раскрывающемся меню щелкните Ссылка в новой проблеме.

   

5. В поле «Название» введите название проблемы.

6. В поле текста комментария введите описание проблемы. 1. Если вы являетесь координатором проекта, вы можете назначить проблему другому пользователю, добавить ее на панель проекта, связать ее с вехой или применить метку. 1. Закончив, нажмите кнопку Отправить новую проблему.

Создание проблемы из обсуждения

Пользователи с разрешением на рассмотрение в репозитории могут создавать проблемы из обсуждений.

При создании проблемы из обсуждения содержимое записи обсуждения будет автоматически включено в текст проблемы с сохранением меток. Создание проблемы из обсуждения не преобразует обсуждение в проблему и не удаляет его. Дополнительные сведения о GitHub Discussions см. в разделе Сведения об обсуждениях.

1. Под именем репозитория или организации щелкните Обсуждения.

   1. В списке обсуждений щелкните обсуждение, которое нужно просмотреть.

2. На правой боковой панели щелкните Создать проблему из обсуждения.

   

3. В поле «Название» введите название проблемы.

4. В поле текста комментария введите описание проблемы. 1. Если вы являетесь координатором проекта, вы можете назначить проблему другому пользователю, добавить ее на панель проекта, связать ее с вехой или применить метку. 1. Закончив, нажмите кнопку Отправить новую проблему.

Создание проблемы из проекта

Вы можете быстро создавать проблемы, не выходя из проекта. При использовании представления, сгруппированного по полю, создание проблемы в этой группе автоматически задает для поля новой проблемы значение группы. Например, если сгруппировать представление по параметру «Состояние», при создании проблемы в группе «Todo» для новой проблемы автоматически будет задано значение «Todo». Дополнительные сведения о проектах см. в разделе Сведения о Projects.

1. Перейдите к своему проекту

2. В нижней части таблицы, группы элементов или столбца в макете доски щелкните .

   

3. Щелкните Создать проблему.

4. В верхней части диалогового окна «Создание новой проблемы» выберите репозиторий, в котором должна быть создана новая проблема.

   

5. Под раскрывающимся списком репозитория введите название новой проблемы.

6. При необходимости используйте поля под полем заголовка, чтобы задать назначенных, метки и вехи и добавить новую проблему в другие проекты.

7. При необходимости введите описание проблемы.

8. При необходимости, если вы хотите создать дополнительные проблемы, выберите Создать еще , и диалоговое окно снова откроется при создании проблемы.

9. Нажмите кнопку Create (Создать).

Создание проблемы из заметки классический проект

Если вы используете классический проект для отслеживания и определения приоритетов работы, вы можете преобразовать заметки в проблемы. Дополнительные сведения см. в разделах Сведения о projects (classic) и Добавление заметок в project (classic).

Создание проблемы из элемента списка задач

При обработке проблемы можно использовать списки задач, чтобы разбить работу на небольшие задачи и отслеживать весь комплекс работ до их завершения. Если задача требует дальнейшего отслеживания или обсуждения, вы можете преобразовать задачу в проблему. Для этого наведите указатель на задачу и щелкните значок в правом верхнем углу задачи. Дополнительные сведения см. в разделе Сведения о списках задач.

Создание проблемы из запроса URL-адреса

Для создания проблем можно использовать параметры запроса. Параметры запроса — это необязательные части URL-адреса, которые можно настроить для совместного использования определенного представления веб-страницы, например результатов поиска с фильтрами или шаблона проблемы на GitHub. Чтобы создать собственные параметры запроса, необходимо сопоставить пару ключа и значения.

Чтобы использовать эквивалентный параметр запроса, необходимо иметь соответствующие разрешения для любого действия. Например, потребуется разрешение, чтобы добавить метку в проблему для использования параметра запроса labels. Дополнительные сведения см. в разделе Роли репозиториев для организации.

Если вы создадите недопустимый URL-адрес, используя параметры запроса, или если у вас нет соответствующих разрешений, URL-адрес вернет страницу ошибки 404 Not Found. Если вы создаете URL-адрес, превышающий ограничения сервера, он вернет страницу ошибки 414 URI Too Long.

Вы также можете использовать параметры запроса URL-адреса для заполнения настраиваемых текстовых полей, определенных в шаблонах форм проблем. Параметры запроса для полей формы проблемы также можно передать в средство выбора шаблонов проблем. Дополнительные сведения см. в разделе Синтаксис для схемы формы GitHub.

Создание проблемы из оповещения code scanning

Если для отслеживания работы и расстановки приоритетов вы используете проблемы, с их помощью можно также отслеживать оповещения code scanning.
Дополнительные сведения о создании проблем для отслеживания оповещений code scanning см. в разделе [AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/tracking-code-scanning-alerts-in-issues-using-task-lists).

Дополнительные материалы

• «Создание документов на GitHub»

3 ответа

Лучший ответ

>>> import subprocess
>>> p = subprocess.Popen(['git', 'cat-file', '-p', 'HEAD'], stdout=subprocess.PIPE)
>>> o = p.stdout.read()
>>> hdr, body = o.split('nn', 1)
>>> hdr = hdr.splitlines()

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author xc5x99x89x83@xc8x96x97x97x85x99 <x88x96x97x97x85x99|x96x94x95x89x86x81x99x89x96xa4xa2Kx96x99x87> 1528844508 -0700',
 'committer xc5x99x89x83@xc8x96x97x97x85x99 <x88x96x97x97x85x99|x96x94x95x89x86x81x99x89x96xa4xa2Kx96x99x87> 1528844508 -0700',
 'encoding cp037']

>>> body.decode('cp037')
u'Well, this should be interesting.x8e'

$ iconv -f cp037
iconv: conversion from cp037 unsupported

>>> import subprocess
>>> p = subprocess.Popen(['iconv', '-f', 'cp037'], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
>>> so, se = p.communicate(s)
>>> so
'Eric Hopperxc2x80x14hopper@omnifarious.orgxc2x9e'

GitHub allowed us to make pre-build issue templates in the form of markdown files which the person reporting the bug could fill out. This was better than presenting the person reporting the bug with a blank textbox but it could get a bit clumsy at times and many wouldn’t follow the format. GitHub now has got an option to build a form that one can fill out as a bug report. Note that Issue forms are in beta currently.

Getting Started

GitHub Issue forms are currently only available for public repositories so we need a public repository to work with.

Next, we need to create a folder called .github/ISSUE_TEMPLATE and then add a yml file. Let us call this bug_report.yml.
Our path will be .github/ISSUE_TEMPLATE/bug_report.yml.

Filling out the template yml file

We are going to make a simple form to file a bug report so let’s get started

First, let us add a name:

name: 🐛Bug Report

We will also add a description, title, and some labels

description: File a bug report here
title: "[BUG]: "
labels: ["bug"]

We can also add an assignee (this is optional) —

assignees: ["AnishDe12020"]

Now that we are done with metadata, let us start with the body of the issue —

Let us start with adding a small text —

body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!!!

We don’t want the user to file a bug report if a report for that bug already exists so let us add a checkbox

 - type: checkboxes
    id: new-bug
    attributes:
      label: Is there an existing issue for this?
      description: Please search to see if an issue already exists for the bug you encountered.
      options:
      - label: I have searched the existing issues
        required: true

Here we have specified the type as a checkbox and added the label parameter and description attributes. We have then added a label parameter to the checkbox and made it a required field as we always want it to be checked by the user.

Now let us ask the user for a description of the bug —

  - type: textarea
    id: bug-description
    attributes:
      label: Description of the bug
      description: Tell us what bug you encountered and what should have happened
    validations:
      required: true

Notice how we add an id to the field (this is optional) and we have also added a description attribute. We can also add a placeholder attribute but let us leave that for this one. We have also made the field required by setting the required parameter to true in the validations section. The label attribute is the only required parameter.

We can also ask them to tell is the steps to reproduce the bug

  - type: textarea
    id: steps-to-reproduce
    attributes:
      label: Steps To Reproduce
      description: Steps to reproduce the behavior.
      placeholder: Please write the steps in a list form
    validations:
      required: true

This is similar to the bug-report field but we have added a placeholder this time.

Now let us see how we can add a dropdown. Say we got 5 versions of our apps and want the users to tell us in which version of the app the issue is occurring. We will also give them the option to choose multiple versions in case the issue is occurring on more than 1 version

  - type: dropdown
    id: versions
    attributes:
      label: Which version of the app are you using?
      description: If this issue is occurring on more than 1 version of the app, select the appropriate versions.
      multiple: true
      options:
       - 1.0.0
       - 1.1.0
       - 1.2.0
       - 2.0.0
       - 2.1.0
    validations:
      required: true

At last, this is how our bug_report.yml should look like —

name: 🐛Bug Report
description: File a bug report here
title: "[BUG]: "
labels: ["bug"]
assignees: ["AnishDe12020"]
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!!!
  - type: checkboxes
    id: new-bug
    attributes:
      label: Is there an existing issue for this?
      description: Please search to see if an issue already exists for the bug you encountered.
      options:
      - label: I have searched the existing issues
        required: true
  - type: textarea
    id: bug-description
    attributes:
      label: Description of the bug
      description: Tell us what bug you encountered and what should have happened
    validations:
      required: true
  - type: textarea
    id: steps-to-reproduce
    attributes:
      label: Steps To Reproduce
      description: Steps to reproduce the behavior.
      placeholder: Please write the steps in a list form
    validations:
      required: true
  - type: dropdown
    id: versions
    attributes:
      label: Which version of the app are you using?
      description: If this issue is occurring on more than 1 version of the app, select the appropriate versions.
      multiple: true
      options:
       - 1.0.0
       - 1.1.0
       - 1.2.0
       - 2.0.0
       - 2.1.0
    validations:
      required: true

Now you should commit the file.

Now if we try to create an issue, we will be presented with this page —

We would see multiple options if we made more templates but we have only one right now so let us see if it works

Notice how the label and assignee has been added —

On submitting the issue, it will be created like any other issue —

You can see the repository for this tutorial here

You can also see the schema for GitHub issue forms here