Setting up Tickets

SINCE 1.4.0

By default, Gitblit is not configured for Tickets. There are several reasons for this, but the most important one is that you must choose the persistence backend that works best for you.

tickets.service

RESTART REQUIRED

The hardest part of setting up Gitblit Tickets is deciding which backend to use. Three implementations are provided, each with different strengths and weaknesses.

File Ticket Service

tickets.service = com.gitblit.tickets.FileTicketService

Your ticket journals are persisted to tickets/{shard}/{id}/journal.json. These journals are stored on the filesystem within your .git directory.

Branch Ticket Service

tickets.service = com.gitblit.tickets.BranchTicketService

Your ticket journals are persisted to id/{shard}/{id}/journal.json. These journals are stored on an orphan branch, refs/meta/gitblit/tickets, within your repository. This allows you to easily clone your entire ticket history to client working copies or to mirrors.

Redis Ticket Service

tickets.service = com.gitblit.tickets.RedisTicketService

Your ticket journals are persisted to a Redis data store. Make sure you configure your Redis instance for durability!! This particular service is highly-scalable and very fast. Plus you can use all of the power of Redis replication, should you want.

The main drawback to this service is that Redis is primarily a Unix tool and works best on a Unix server. Microsoft is engaged with the Redis community and they do maintain a semi-active port of Redis for Windows servers.

tickets.redis.url = redis://(:{password}@){hostname}:{port}(/{databaseId})

examples

tickets.redis.url = redis://localhost:6379
tickets.redis.url = redis://:password@localhost:6379/2

Other Settings

You should also review the following settings before using Gitblit Tickets to understand what controls are available.

web.canonicalUrl

web.canonicalUrl = https://localhost:8443

The Tickets feature sends rich email notifications to those who are participating or watching a ticket. In order for the links in those emails to work properly, you really should set the canonical web url of your Gitblit install. This url should be your public url used to browse and navigate the website.

tickets.acceptNewTickets

tickets.acceptNewTickets = true

This setting is used to globally disable manual creation of tickets through the web ui. You may still create proposal tickets by pushing patchsets.

You may decide to disable creation of new tickets at the repository level in the Edit Repository page, however if this global setting is false, it will trump the repository setting.

tickets.acceptNewPatchsets

tickets.acceptNewPatchsets = true

This setting is used to globally disable accepting new patchsets. If this set false, you can not create proposal tickets BUT you can still create tickets through the web ui, assuming tickets.acceptNewTickets=true.

You may decide to disable accepting new patchsets at the repository level in the Edit Repository page, however if this global setting is false it will trump the repository setting.

tickets.requireApproval

tickets.requireApproval = false

This setting is the default for requiring an approve review score (+2) before enabling the merge button in the web ui. This setting is not considered during the push process so an integrator may push a merged ticket disregarding this approval setting. The setting only affects the web ui and may be configured per-repository.

tickets.indexFolder

RESTART REQUIRED

tickets.indexFolder = ${baseFolder}/tickets/lucene

This is the destination for the unified Lucene ticket index. You probably won't need to change this, but it's configurable if the need arises.

Setting up a Repository

Controlling Tickets

Each repository can accept or reject tickets and/or patchsets by the repository settings.

Issue-Tracker, no patchsets
allow new tickets = true
accept patchsets = false
Proposals only, no user-reported issues
allow new tickets = false
accept patchsets = true
Issue-tracker AND Proposals
allow new tickets = true
accept patchsets = true
No tickets whatsoever
allow new tickets = false
accept patchsets = false

Controlling Merges

Gitblit has a simple review scoring mechanism designed to indicate overall impression of the patchset. You may optionally configure your repository to require an approval score for a patchset revision BEFORE the Merge button is displayed/enabled. This per-repository setting is not respected if an integrator pushes a merge. This setting is only used to control the web ui.

Milestones

Milestones are a way to group tickets together. Milestones are specified for each repository and are stored in the repository git config file. Repository owners may create milestones through the web ui in the Tickets page on the Milestones tab.

[milestone "v1.5.0"]
    status = Open
    due = 2014-06-01
    color = "#00f000"

Please note the date format for the due field: yyyy-MM-dd.