-
Notifications
You must be signed in to change notification settings - Fork 21
Mark Cost Attribution end_month parameter as not required #2027
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -413,8 +413,8 @@ def get_hourly_usage_with_http_info(filter_timestamp_start, filter_product_famil | |
| # Get Monthly Cost Attribution. | ||
| # | ||
| # @see #get_monthly_cost_attribution_with_http_info | ||
| def get_monthly_cost_attribution(start_month, end_month, fields, opts = {}) | ||
| data, _status_code, _headers = get_monthly_cost_attribution_with_http_info(start_month, end_month, fields, opts) | ||
| def get_monthly_cost_attribution(start_month, fields, opts = {}) | ||
| data, _status_code, _headers = get_monthly_cost_attribution_with_http_info(start_month, fields, opts) | ||
| data | ||
| end | ||
|
|
||
|
|
@@ -438,16 +438,16 @@ def get_monthly_cost_attribution(start_month, end_month, fields, opts = {}) | |
| # This endpoint is only accessible for [parent-level organizations](https://docs.datadoghq.com/account_management/multi_organization/). | ||
| # | ||
| # @param start_month [Time] Datetime in ISO-8601 format, UTC, precise to month: `[YYYY-MM]` for cost beginning in this month. | ||
| # @param end_month [Time] Datetime in ISO-8601 format, UTC, precise to month: `[YYYY-MM]` for cost ending this month. | ||
| # @param fields [String] Comma-separated list specifying cost types (e.g., `<billing_dimension>_on_demand_cost`, `<billing_dimension>_committed_cost`, `<billing_dimension>_total_cost`) and the proportions (`<billing_dimension>_percentage_in_org`, `<billing_dimension>_percentage_in_account`). Use `*` to retrieve all fields. Example: `infra_host_on_demand_cost,infra_host_percentage_in_account` To obtain the complete list of active billing dimensions that can be used to replace `<billing_dimension>` in the field names, make a request to the [Get active billing dimensions API](https://docs.datadoghq.com/api/latest/usage-metering/#get-active-billing-dimensions-for-cost-attribution). | ||
| # @param opts [Hash] the optional parameters | ||
| # @option opts [Time] :end_month Datetime in ISO-8601 format, UTC, precise to month: `[YYYY-MM]` for cost ending this month. | ||
| # @option opts [SortDirection] :sort_direction The direction to sort by: `[desc, asc]`. | ||
| # @option opts [String] :sort_name The billing dimension to sort by. Always sorted by total cost. Example: `infra_host`. | ||
| # @option opts [String] :tag_breakdown_keys Comma separated list of tag keys used to group cost. If no value is provided the cost will not be broken down by tags. To see which tags are available, look for the value of `tag_config_source` in the API response. | ||
| # @option opts [String] :next_record_id List following results with a next_record_id provided in the previous query. | ||
| # @option opts [Boolean] :include_descendants Include child org cost in the response. Defaults to `true`. | ||
| # @return [Array<(MonthlyCostAttributionResponse, Integer, Hash)>] MonthlyCostAttributionResponse data, response status code and response headers | ||
| def get_monthly_cost_attribution_with_http_info(start_month, end_month, fields, opts = {}) | ||
| def get_monthly_cost_attribution_with_http_info(start_month, fields, opts = {}) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ⚪ Code Quality ViolationAvoid using a hash as an optional parameter (...read more)The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect. This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand. To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using |
||
| unstable_enabled = @api_client.config.unstable_operations["v2.get_monthly_cost_attribution".to_sym] | ||
| if unstable_enabled | ||
| @api_client.config.logger.warn format("Using unstable operation '%s'", "v2.get_monthly_cost_attribution") | ||
|
|
@@ -462,10 +462,6 @@ def get_monthly_cost_attribution_with_http_info(start_month, end_month, fields, | |
| if @api_client.config.client_side_validation && start_month.nil? | ||
| fail ArgumentError, "Missing the required parameter 'start_month' when calling UsageMeteringAPI.get_monthly_cost_attribution" | ||
| end | ||
| # verify the required parameter 'end_month' is set | ||
| if @api_client.config.client_side_validation && end_month.nil? | ||
| fail ArgumentError, "Missing the required parameter 'end_month' when calling UsageMeteringAPI.get_monthly_cost_attribution" | ||
| end | ||
| # verify the required parameter 'fields' is set | ||
| if @api_client.config.client_side_validation && fields.nil? | ||
| fail ArgumentError, "Missing the required parameter 'fields' when calling UsageMeteringAPI.get_monthly_cost_attribution" | ||
|
|
@@ -480,8 +476,8 @@ def get_monthly_cost_attribution_with_http_info(start_month, end_month, fields, | |
| # query parameters | ||
| query_params = opts[:query_params] || {} | ||
| query_params[:'start_month'] = start_month | ||
| query_params[:'end_month'] = end_month | ||
| query_params[:'fields'] = fields | ||
| query_params[:'end_month'] = opts[:'end_month'] if !opts[:'end_month'].nil? | ||
| query_params[:'sort_direction'] = opts[:'sort_direction'] if !opts[:'sort_direction'].nil? | ||
| query_params[:'sort_name'] = opts[:'sort_name'] if !opts[:'sort_name'].nil? | ||
| query_params[:'tag_breakdown_keys'] = opts[:'tag_breakdown_keys'] if !opts[:'tag_breakdown_keys'].nil? | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚪ Code Quality Violation
Avoid using a hash as an optional parameter (...read more)
The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.
This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.
To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using
options = {}in the method definition, declare each parameter likename, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.