Skip to main content

Improve UX for resources shared across multiple CLI projects

Feature RequestCLI

Some customers have multiple CLI projects to segment their checks. For example, a customer monitoring Product A, B, and C might create a CLI project for each (if they’re in separate repos, they want to deploy them separately, etc.)

However, these separate projects might use the same alert channels or status page. Our options now are not ideal:

  • Deploy the shared resources via a separate CLI project. Then, use fromId() in each project to refer to the shared resources. This is the best option, but it can be cumbersome since we need to deploy the shared resources, grab the IDs for any that were created, plug them into the other projects, then deploy those.

  • Create and manage them entirely from the website UI. Then, use fromId() in each project to refer to the shared resources. Not great, ideally all resources should be managed via the CLI.

  • Re-create the shared resources in each project and accept the duplication. This is not ideal and makes it hard to keep those shared resources consistent. It’s also not plausible for something like a shared status page.

Posted by Laura Guo ·
1 comment

Log in to comment and vote

Comments1

  • Hervé Labas

    Team•

    Jul 16

    I guess the main limitation is the 1 resource <> 1 project assignment and that it’d be nice to have a notion of library that can be shared across projects so you still manage the resource as code, in one place, yet can have projects depend on each other (or more specifically, projects depend on libraries)?

    What I wonder is how far that gets us into redoing some sort of dependency management ourselves, versus leaving that to actual package managers.

    Maybe we could already figure out a better option than fromId and allow more qualified names (logical ID comes to mind) to make the reference predictable and not requiring a deployment to have happened to be able to reference a shared resource. That’d also allow deploying on different environments without risking different IDs for each, making the current fromId impossible to use.