1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
## Setting up Tickets
*PREVIEW 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/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. While there is a Windows port, sort-of maintained by Microsoft, it is not actively updated.
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. Currently milestones are specified at the repository level and are stored in the repository git config file. Gitblit's internal architecture has all the methods necessary to maintain milestones, but this functionality is not yet exposed through the web ui. For now you will have to control milestones manually with a text editor.
[milestone "v1.5.0"]
status = Open
due = 2014-06-01
color = "#00f000"
Please note the date format for the *due* field: yyyy-MM-dd.
|
