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 GitLab itself - please see this article. The text below assumes that you already completed GitLab installation.

Below are detailed steps for recommended GitLab 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 projects 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 projects 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.

Important: We recommend to use Premium GitLab account, because it gives you access to a "Weight" field (used for "Count" / "Occurrences"). This means that you will be able to sort your bugs to find top priority bugs.

Creating user accounts

1. Register user account on GitLab:

2. This account will be used to post bug reports. Once logged in - go to settings for your profile and find "Access Tokens":

3. Enter arbitrary name (like "For EurekaLog") and select appropriate scopes (select "api").

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 projects

1. Log in as admin account and create a new project:

2. Remember the name of the project - you will use it later (see below).

3. [Optional] Set up project's visibility and access rights.

4. Invite bug reporter user account (created above) as "Reporter" to the project:

5. 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 GitLab are implemented as Releases, which are based on Tags. Please note that Git has limitations on tag names.

To create a new version in GitLab:

•	Commit all pending changes to source code;

•	Open "Project Overview" / "Releases" and click on the "New release" button:

•	Use version (such as "1.0.0.0", "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.

Alternatively:

•	Open "Repository" / "Tags" and click on the "New tag" button:

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

Don't forget to enter the "Message" - otherwise GitLab will create a lightweight tag.

Note: you can also create Release for the new tag in GitLab later.

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.

EurekaLog setup

1. Enter GitLab details into EurekaLog settings of your projects:

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

Testing

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

2.	Resolve any found issues (access denied, wrong values in fields, etc).

3.	Once successful and there is new issue in GitLab - 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 GitLab. 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 GitLab 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 GitLab.

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 (Releases/Tags) when you ship new release of your software.

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