Gradle build-scans create links to the build-scans hosted on https://scans.gradle.com, but it's just a loose link. The only way to delete this published build scan is to keep the link somewhere.
Our Current Implementation
Currently every build-scan link is appended to a file in the local file system (in an gitignore'd folder in the project's root directory). This isn't ideal. It can be easy to lose these links to cleans, etc, isn't easy to share with others, and storing it outside of this location leads to other annoyances.
Goal
Email is a cheap and easy way to aggregate and manage this for now. Let's just make sure that users can subscribe to only getting their own notifications or getting the global notifications. Ideally, those who publish a build-scan would be responsible for their build-scans in a single source of truth.
Handle storing credentials in a sane/secure (and preferably seamless) way.
Implementation Notes
Use a service-oriented gmail address to send the email
Spike what is ideal to use when it comes to the gmail side of things (e.g. shared inbox multiple people can access from their individual work inbox? Is that possible)
This might be a good start for the gradle-side component to this as it doesn't use a local smtp server.
Gradle build-scans create links to the build-scans hosted on https://scans.gradle.com, but it's just a loose link. The only way to delete this published build scan is to keep the link somewhere.
Our Current Implementation
Currently every build-scan link is appended to a file in the local file system (in an gitignore'd folder in the project's root directory). This isn't ideal. It can be easy to lose these links to cleans, etc, isn't easy to share with others, and storing it outside of this location leads to other annoyances.
Goal
Email is a cheap and easy way to aggregate and manage this for now. Let's just make sure that users can subscribe to only getting their own notifications or getting the global notifications. Ideally, those who publish a build-scan would be responsible for their build-scans in a single source of truth.
Handle storing credentials in a sane/secure (and preferably seamless) way.
Implementation Notes
This might be a good start for the gradle-side component to this as it doesn't use a local smtp server.