-
Notifications
You must be signed in to change notification settings - Fork 5
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
aws-catalog plugins #27
Conversation
d90c0e0
to
eeb5854
Compare
eeb5854
to
a73f5c2
Compare
{ | ||
metadata: { | ||
annotations: { | ||
[arn.ANNOTATION]: instanceArn, | ||
[ANNOTATION_LOCATION]: instanceArn, | ||
[ANNOTATION_ORIGIN_LOCATION]: instanceArn, | ||
}, | ||
}, | ||
}, |
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.
not for this change but i'm trying to better understand how refreshing on a per entity level works. in the out of the box AboutCard
there's a guard against refreshing anything with a location that's not url:
or file:
(not for any reason we have to worry about with arn:
locations)
ui aside, i'm a little confused how refreshing an individual entity works. (maybe has to do with these readLocation
on a processor, which is separate from the provider: https://backstage.io/docs/features/software-catalog/external-integrations#creating-a-catalog-data-reader-processor.)
anyway, at some point we'll want to be able to refresh one of our dbs via the ui i'm sure, so wanted to flag that here
/** | ||
* A db instance from the AWS SDK. | ||
* @public | ||
*/ | ||
export type RDSDBInstance = DBInstance; | ||
/** | ||
* Input for the RDSDescribeDBInstancesCommand. | ||
* @public | ||
*/ | ||
export type RDSDescribeDBInstancesCommandInput = | ||
DescribeDBInstancesCommandInput; |
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.
fwiw, i did this here and in the okta provider as it makes it a bit easier than us rewriting the interface or having users also add the aws library when they use the provider, but it does mean we risk the following:
- aws sdk pushes a breaking change to one of these aliased types
- we bump the version and release as a non major change (not realizing some interface has updated)
- user code breaks
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.
That's a good point. I'm of the opinion that, because AWS also follows semver, this risk is acceptable as long as we never bump the AWS major version without also bumping our own.
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.
awesome
🎉 This PR is included in version 1.0.0 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.0.0 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.0.2 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 2.0.0 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 2.0.0 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.0.0 🎉 The release is available on Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.0.2 🎉 The release is available on Your semantic-release bot 📦🚀 |
This PR adds plugins capable of loading AWS resources into the catalog.