The ui-bootstrap.json
file contains config about each service type. Click here to see the default file provided. Service types are defined here.
This config file provides paths/keys of various variables in the schema of the service type provided by the backend. The possible keys are:
release.version
- release version keyrelease.config_array
- release config_array keyrelease.extras
- list of extra release keysperConfigSchemaPath
- path to configsname
- config name keyversion
- config version keyauthor
- config author keydescription
- config description key
It also provides a key to define a JavaScript function that will return the labels for the service. This is done through the labelsFunc
key.
Testing can be enabled or disable through these keys:
testing.perConfigTestEnabled
- whether a single config can be testedtesting.releaseTestEnabled
- whether the entire release can be testedtesting.testCaseEnabled
- whether test cases can be created
Checkboxes for quick filtering can be added per service in the checkboxes
key. Filters can be added based on different fields such as the author or the labels of the config. Below is example of the config of a checkbox. It defined one checkbox group called Severity
with two checkboxes: high
and low
. The pattern defined for each checkbox is matched against the given field. The given field can be:
- a
string
- the pattern is matched against it - a
list
- the pattern has to match one of the items
"checkboxes": {
"severity": {
"high": {
"field": "labels",
"pattern": "^severity:low$"
},
"low": {
"field": "labels",
"pattern": "^severity:high$"
}
}
}
The override
key can be used to override any of the above properties for a specific service name
(all the above is per service type
). If there are two services of the same type different config can be applied to one using this key.
Example: Overriding the testing.releaseTestEnabled
property for the myalerts
service:
"override": {
"myalerts": {
"testing": {
"releaseTestEnabled": false
}
}
}