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('\n\n', 1)
>>> hdr = hdr.splitlines()

The header lines are long, even after splitting:

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 1528844508 -0700',
 'committer \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 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 Hopper\xc2\x80\x14hopper@omnifarious.org\xc2\x9e'

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 >?

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('\n\n', 1)
>>> hdr = hdr.splitlines()

The header lines are long, even after splitting:

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 1528844508 -0700',
 'committer \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 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 Hopper\xc2\x80\x14hopper@omnifarious.org\xc2\x9e'

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 >?

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

3 ответа

Лучший ответ

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

>>> import pprint
>>> pprint.pprint(hdr)
['tree 79036d838fc5ce13e849949d02e6048c2d33c561',
 'author \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 1528844508 -0700',
 'committer \xc5\x99\x89\x83@\xc8\x96\x97\x97\x85\x99 <\x88\x96\x97\x97\x85\x99|\x96\x94\x95\x89\x86\x81\x99\x89\x96\xa4\xa2K\x96\x99\x87> 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 Hopper\xc2\x80\x14hopper@omnifarious.org\xc2\x9e'