This article is part of Managing bug report in issue tracker series.
See managing bug reports in issue tracker for common information. Please, read it first. For common information and setup of GitHub itself - please see this article. The text below assumes that you already completed GitHub installation.
Below are detailed steps for recommended GitHub setup for automatic bug report submission.
Some steps below are optional, some steps must be executed only once (like account set up), other are executed from time to time (like creating new repositories for your new products) and the rest are executed regularly (like creating product versions).
Full list of necessary actions contains:
Please note that all actions below are just examples. It's recommendation, but it's not necessary to be absolutely like that. You may use another configuration.
Creating user accounts1. Register user account on GitHub:
2. This account will be used to post bug reports. Once logged in - go to Developer settings for your profile:
Then open "Personal access tokens" and select "Generate new token":
3. Enter arbitrary name (like "For EurekaLog") and select appropriate scopes (e.g. select "repo" and/or "public_repo").
4. Save/copy the newly created API token - you will need it later (see below).
5. [Optional] We recommend to enable two-factor auth, disable e-mail notifications and make profile private.
Creating repositories1. Log in as admin and create a new repository:
2. Remember the name of the repository - you will use it later (see below).
3. [Optional] Set up project's visibility and access rights.
4. Invite bug reporting user account (created above) as collaborator:
5. "Issues" (in other words, internal bug tracker) should be enabled in the repository by default. However, if you are using an existing repository - make sure that "Issues" are enabled in repository's options.
6. Create versions for the project. If you don't use versioning (highly unrecommended) - you can skip this step.
You should create new version for each release of your software. I.e. when you release (publish on site, send to custom, etc) "YourSoftware 1.0.0.0" - you need to create "1.0.0.0" version. When you release update: "YourSoftware 1.0.1.0" - you need to add "1.0.1.0" version.
Version strings can be arbitrary like "1", "1.0", "1.0.1", "v1.0.1.0" or even "v1.0.1.0-beta-3". However, it's recommended to use four-number versions (with optional "v" prefix) with optional textual description, for example: "1.0.1.0" and "1.0.1.0-beta-3".
Versions in GitHub are implemented as Releases, which are based on Tags. Please note that Git has limitations on tag names.
To create a new version in GitHub:
Creating a new release will also create a new tag.
When reporting - version are taken from file's version information, so you must supply the corresponding version in description of your .exe or .dll files.
Note: EurekaLog will use closest match.
Creating attaches storageGitHub does not support file attaches. Therefore, if you want to receive bug report files from EurekaLog - you have to create a special "eurekalog_reports" branch to your repository. EurekaLog will use that branch to store files.
Open your repository, switch to the "Code" tab and open branches selector:
Type in "eurekalog_reports" (without quotes) to create a new branch:
Once new branch is created - switch back to "main". EurekaLog will automatically search for the "eurekalog_reports" branch to use it as storage for files.
EurekaLog setup1. Enter GitHub details into EurekaLog settings of your projects:
GitHub settings filled into EurekaLog options
2. Set any additional/common send options.
3. Add any custom data, additional attached files, write necessary event handlers, set exception filters, etc, etc.
Testing1. Test sending. You can do this right in the EurekaLog send options dialog - by clicking on "Test..." button. This will send test bug report.
Suggested actions are:
These actions should test that sending is actually working.
2. Now it's time to test your application-specific sending.
Now your application is ready for deployment.
Maintaining projects1. [Optional] You need to create or update project versions (Releases/Tags) when you ship new release of your software.
See also:
|