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.
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.
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.
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.
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
You should also review the following settings before using Gitblit Tickets to understand what controls are available.
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 = 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 = 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 = 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.
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.
Each repository can accept or reject tickets and/or patchsets by the repository settings.
allow new tickets = true
accept patchsets = false
allow new tickets = false
accept patchsets = true
allow new tickets = true
accept patchsets = true
allow new tickets = false
accept patchsets = false
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 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.