Root > Solving bugs in your code > Managing bug reports in issue tracker > Bug trackers setup > GitHub setup

GitHub setup

Previous pageReturn to chapter overviewNext page   

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:

1. Creating user accounts (single act or per product)
2. Creating repositories and setting it up (single act or per product)
3. EurekaLog setup (per product)
4. Testing (as required)
5. Maintaining project (regularly or from time to time)


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 accounts

1. 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 repositories

1. 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" (e.g. 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" - you need to create "" version. When you release update: "YourSoftware" - you need to add "" 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: "" and "".


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:

Commit all pending changes to source code;
Navigate to the main page of the repository; to the right of the list of files, click "Releases" or "Latest release", and then click on the "Draft a new release" button.




Use version (such as "", "v1.0.0.0", or "v1.0.0.0-Stable-Public-Release") as "Tag name" when creating a release.



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 storage

GitHub 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 setup

1. 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.




1. 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:

1. Click on "Test..." button to test sending and creating of a new bug issue in GitHub.
2. Resolve any found issues (access denied, wrong values in fields, etc).
3. Once successful and there is new issue in GitHub - click on "Test..." button again. This should test updating project.
4. Resolve any found issues (access denied, etc).
5. Once successful - close existing test issue in GitHub. Optionally - add a note with special tags (see customizing feedback).
6. Click on "Test..." button again. This should test sending old (already fixed) bugs (see: issues workflow).
7. Ensure there is no error messages, no problems. You should get "success, this bug is fixed" kind of behavior. Exact behavior depends on your settings.
8. Delete test issue in GitHub after testing.


These actions should test that sending is actually working.


2. Now it's time to test your application-specific sending.


1. Place debug code in your application to raise a test exception and cause a test leak (if you've enabled leaks collecting).
2. Run your application and invoke this test code.
3. Let application crash and process bug (show dialog, send bug report, etc).
4. Ensure that behavior is expected.
5. Ensure that you get all files and additional information in GitHub.
6. Remove test code from your application.


Now your application is ready for deployment.



Maintaining projects

1. [Optional] You need to create or update project versions (e.g. Releases/Tags) when you ship new release of your software.



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2022-01-14
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: