When using IntelliJ IDEA, use the 'default' style. This is matched by checkstyle, which is invoked when running maven.
Notifications might host multiple API versions at the same time. This is done by replacing some calls depending the requested version. The version is part of the URL (as per platform guidelines). When starting a new version, most of the APIs have the same implementation. To make the process of adding a new API version as easy as possible the following strategy is used.
The @Path annotation in each resource is moved to an inner class with the version name. e.g.
@Path("api/notifications/v1.0/endpoints")
class EndpointResource {
@GET
public void myPath() {
}
}becomes:
class EndpointResource {
@Path("api/notifications/v1.0/endpoints")
public static class V1 extends EndpointResource {
}
@Path("api/notifications/v2.0/endpoints")
public static class V2 extends EndpointResource {
}
@GET
public void myPath() {
}
}Consider we want a new implementation of an API, with different behavior and even params.
class EndpointResource {
@Path("api/notifications/v1.0/endpoints")
class V1 extends EndpointResource {
}
@Path("api/notifications/v2.0/endpoints")
class V2 extends EndpointResource {
}
@GET
public void myPath() {
}
@POST
public void myOldPostRequest() {
// ... do some old stuff
}
}We would update it as follow:
class EndpointResource {
@Path("api/notifications/v1.0/endpoints")
class V1 extends EndpointResource {
@POST
public void myOldPostRequest() {
// ... do some old stuff
}
}
@Path("api/notifications/v2.0/endpoints")
class V2 extends EndpointResource {
@POST
public List<?> myNewRequest(@QueryParam int coolParam) {
// ... New API. Different params, different return value
}
}
@GET
public void myPath() {
}
}In this example, we moved the old request of the V1 class and added the new behavior in V2. That’s it!
This project uses MockServer to mock external services during the tests execution.
The MockServer log is disabled by default to reduce the noise in the application log. It can be enabled by adding the following argument to the Maven build command:
-Dmockserver.logLevel=WARN|INFO|DEBUG|TRACEDetails about each MockServer log level are available in the MockServer documentation.
This project uses the Clowder Config Source from https://github.com/RedHatInsights/clowder-quarkus-config-source.
To configure this source to use a different file than /cdappconfig/cdappconfig.json you can use the property clowder.file=/path/to/file.json.
If you deploy notifications-backend on ephemeral, the database may not contain all the data you need for your tests.
It is possible to load data on ephemeral when the backend pod starts, but this is restricted to three kinds of database
records: Bundle, Application and EventType.
There are two ways of loading that data, as explained below. Both can be used at the same time as long as the name
field is globally unique for each type of database record. If there is no name conflict, the data from both sources
will be inserted into the database.
The notifications-backend ClowdApp template contains an environment variable definition that can be used to load data:
env:
- name: NOTIFICATIONS_EPHEMERAL_DATA
valueFrom:
configMapKeyRef:
name: notifications-ephemeral-data
key: ephemeral_data.json
optional: trueIf a ConfigMap named notifications-ephemeral-data is created by any of the pods present in the ephemeral namespace,
the backend pod will consume that ConfigMap as an environment variable and put the value of the ephemeral_data.json
key into the NOTIFICATIONS_EPHEMERAL_DATA environment variable.
|
Tip
|
The ConfigMap is optional, it is not a requirement for the notifications-backend pod deployment.
|
Here is an example of the ConfigMap you could add to your application ClowdApp template:
- apiVersion: v1
kind: ConfigMap
metadata:
name: notifications-ephemeral-data
data:
ephemeral_data.json: |
{
"bundles": [
{
"name": "my-bundle",
"display_name": "My Bundle",
"applications": [
{
"name": "my-app",
"display_name": "My Application",
"event_types": [
{
"name": "my-event-type",
"display_name": "My Event Type",
"description": "This is my event type"
}
]
}
]
}
]
}You can also load data on ephemeral by creating a pull request that modifies the ephemeral_data.json file which is hosted in this repository. This file may contain ephemeral data from other applications so please be careful not to delete or edit data that would belong to another team.
Here is an example of the data structure allowed in ephemeral_data.json:
{
"bundles": [
{
"name": "my-bundle",
"display_name": "My Bundle",
"applications": [
{
"name": "my-app",
"display_name": "My Application",
"event_types": [
{
"name": "my-event-type",
"display_name": "My Event Type",
"description": "This is my event type"
}
]
}
]
}
]
}For the requests as well as for the responses for querying the IT User Service we can use this online generator to generate the clases by pasting the json files there: https://www.jsonschema2pojo.org/
While the Grafana dashboard on stage gets updated automatically after merging a PR that changes the dashboard, prod still needs to be updated manually. If you want to update the dashboards on prod after you checked that your changes are working on stage, you need to update the reference in app-interface/data/services/insights/notifications/cicd/ci-int/saas-observability.yml