Change Details

In order to aid with the non-backwards changes that might come out of the refactor, we will want to expose some deprecation metrics. This task is to: * [] add the metric itself to be exposed on the jobs-api prometheus exporter, this can be something like `toolforge_depracated_usage`, with the labels `path` and `method`, `deprecation_id` that would be a unique id to identify the deprecation (ex. if we are deprecating a specific parameter, a whole endpoint, etc.), `user_agent` of the request to the api, to identify the source (feel free to add more if you think of more). A (completely fake) example of entry would be `toolforge_deprecated_usage{path="/v1/tool/mytool/jobs", method="POST", deprecation_id="timeout_parameter", user_agent="mytool; toolforge-weld 1.2.3"}` * [] add a helper in the code to be able to increment easily * [] add a graph in the jobs-api grafana board (https://grafana.wmcloud.org/d/kcAb-KUSz/jobs-api?orgId=1) This will make it way easier to keep track of that process.

In order to aid with the non-backwards changes that might come out of the refactor, we will want to expose some deprecation metrics. This task is to: * [x] add the metric itself to be exposed on the jobs-api prometheus exporter, this can be something like `toolforge_depracated_usage`, with the labels `path` and `method`, `deprecation_id` that would be a unique id to identify the deprecation (ex. if we are deprecating a specific parameter, a whole endpoint, etc.), `user_agent` of the request to the api, to identify the source (feel free to add more if you think of more). A (completely fake) example of entry would be `toolforge_deprecated_usage{path="/v1/tool/mytool/jobs", method="POST", deprecation_id="timeout_parameter", user_agent="mytool; toolforge-weld 1.2.3"}` * [x] add a helper in the code to be able to increment easily * [] add a graph in the jobs-api grafana board (https://grafana.wmcloud.org/d/kcAb-KUSz/jobs-api?orgId=1) This will make it way easier to keep track of that process.

In order to aid with the non-backwards changes that might come out of the refactor, we will want to expose some deprecation metrics. This task is to: * [x] add the metric itself to be exposed on the jobs-api prometheus exporter, this can be something like `toolforge_depracated_usage`, with the labels `path` and `method`, `deprecation_id` that would be a unique id to identify the deprecation (ex. if we are deprecating a specific parameter, a whole endpoint, etc.), `user_agent` of the request to the api, to identify the source (feel free to add more if you think of more). A (completely fake) example of entry would be `toolforge_deprecated_usage{path="/v1/tool/mytool/jobs", method="POST", deprecation_id="timeout_parameter", user_agent="mytool; toolforge-weld 1.2.3"}` * [x] add a helper in the code to be able to increment easily * [] add a graph in the jobs-api grafana board (https://grafana.wmcloud.org/d/kcAb-KUSz/jobs-api?orgId=1) This will make it way easier to keep track of that process.