-
Notifications
You must be signed in to change notification settings - Fork 74
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
DBaaS: Add API endpoint for applying cluster patches #909
DBaaS: Add API endpoint for applying cluster patches #909
Conversation
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.
Looks great, but I did have a suggestion in-line re: operationId
@@ -0,0 +1,47 @@ | |||
operationId: databases_update_installUpdate |
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.
The operation ID is used by client generation tools to produce the method name. For example pydo, our Python client, will end up having a method with the redundant name databases.update_install_update
. This might be more natural:
operationId: databases_update_installUpdate | |
operationId: databases_install_update |
Our linter enforces using consistent operation IDs across our API. As this would be the first PUT using install
, you'll also need to add it here so that it passes:
const PUT = ["update", "promote"]; |
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.
I've pushed an additional commit to allow this to pass the linter check: e41ef07
specification/resources/databases/databases_update_installUpdate.yml
Outdated
Show resolved
Hide resolved
…te.yml Co-authored-by: Andrew Starr-Bochicchio <andrewsomething@users.noreply.github.com>
…te.yml Co-authored-by: danaelhe <42972711+danaelhe@users.noreply.github.com>
|
||
parameters: | ||
- $ref: 'parameters.yml#/database_cluster_uuid' | ||
|
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.
I believe a single line in between should be enough.
Looks good to me |
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
13808615 | Triggered | Basic Auth String | 11eb0dc | specification/resources/databases/models/opensearch_connection.yml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
No description provided.