Local Development and Testing of Recipes

[willtsai]

Overview of feature request

Implement a workflow for platform engineers to develop, test, and iterate on recipes locally before publishing them. This includes the ability to register local recipe files directly in a Radius environment without needing to upload them to an OCI registry, allowing for rapid development and testing cycles. This feature should also support the registration of custom RRTs if applicable.

Acceptance criteria

Here are some ideas to get started:

User Story: As a platform engineer, I want a local development experience for Recipes and RRTs, so that I can iterate on custom Recipes without needing to publish them to an OCI registry:

This scenario outlines how a platform engineer can develop, test, and iterate on Recipes (and associated Radius Resource Types, if custom) using local files before publishing them.

Local Iterative Development of a Custom Recipe for a built-in or custom RRT

A platform engineer wants to customize the behavior of Radius.Compute/containers@2025-05-01-preview for their specific Kubernetes setup by creating a new recipe or modifying an existing one. They want to test these changes locally before publishing the recipe to an OCI registry.

1. Setup Local Development Environment:

   • Ensure Radius CLI is installed and a local Radius control plane is running (e.g., via rad install kubernetes or a local kind cluster).
   • Create or select a local Radius environment for testing (e.g., rad env create my-dev-env or use an existing one).
   • The RRT for Radius.Compute/containers@2025-05-01-preview is assumed to be already known by Radius (as it's a built-in resource type).

2. Create and iterate on the Recipe Locally:

   • Create a new or modify an existing Bicep or Terraform file for the recipe (e.g., ./my-custom-recipes/kubernetes-container/template.bicep).
   • Modify the Bicep/Terraform template file (e.g., template.bicep) to implement the desired custom logic (e.g., add specific annotations, configure a default sidecar, change resource limits).

3. Register the Local Recipe:

   • Use rad recipe register with the --recipe-location pointing to the local recipe template file (or the directory containing the template and schema). This allows testing without publishing to an OCI registry.
   • rad recipe register default --environment my-dev-env --resource-type Radius.Compute/containers@2025-05-01-preview --recipe-location ./my-custom-recipes/kubernetes-container/template.bicep --parameters customParam=valueForDev
   • Radius will validate the recipe against the RRT schema and its own parameter definitions.

4. Define/Deploy an Application Using the Local Recipe:

   • Create or use an existing application Bicep file (app.bicep) that defines an Radius.Compute/containers@2025-05-01-preview resource.
   • Deploy the application to the local test environment: rad deploy ./app.bicep --environment my-dev-env
   • Radius will use the locally registered recipe to provision the container.

5. Test and Debug:

   • Verify the deployment in the target platform (e.g., check Kubernetes resources using kubectl get pods,svc,deploy -n my-app-my-dev-env).
   • Inspect Radius application graph: rad app graph my-app -e my-dev-env

6. Publish the Recipe (Once Satisfied):

   • Once the recipe is finalized, publish it to an OCI registry (for Bicep) or a Terraform module repository.
   • Update any environment configurations or Recipe Packs to point to the published OCI URI instead of the local path for broader use.

Scenario: Using Recipes locally from a Cloned Git Repository

A platform engineer clones a Git repository (e.g., a company's internal IaC repo or a community repo) that contains a collection of RRT definitions (if custom) and their corresponding Recipes as local files.

1. Clone the Repository:

   • git clone https://github.com/my-org/radius-custom-definitions.git
   • cd radius-custom-definitions

2. Inspect Repository Structure:

   • Familiarize with how RRTs (e.g., in a types/ directory) and recipes (e.g., in a recipes/ directory, possibly organized by type) are laid out.

3. Register RRTs from Local Files (if they are custom RRTs):

   • If the repository contains custom RRT definitions (e.g., types/my-custom-widget.yaml), register them to the desired Radius environment.
   • rad resource-type create myCustomWidget -f ./types/my-custom-widget.yaml
   • (If they want to use built-in types like Radius.Compute/containers@2025-05-01-preview, this step can be skipped.)

4. Register Recipes from Local Files:

   • For each core type (or custom RRT) for which a recipe is provided in the cloned repository, register it using its local path.
   • Example for a custom container recipe:
     rad recipe register default --environment my-dev-env --resource-type Radius.Compute/containers@2025-05-01-preview --recipe-location ./recipes/core/kubernetes-custom-container/template.bicep
   • Example for a recipe for a custom RRT:
     rad recipe register default --environment my-dev-env --resource-type Radius.Resources/myWidget --recipe-kind bicep --recipe-location ./recipes/custom/my-widget-recipe/template.bicep

5. Deploy Applications:

   • Developers can now define applications using these RRTs, and Radius will use the locally registered recipes from the cloned repository when deploying to my-dev-env.

This approach allows teams to manage and version their RRTs and recipes in Git, and easily set up development or testing environments by registering these assets directly from their local checkout without needing an intermediate OCI publishing step for every iteration.

Additional context

This feature request was created in response to feedback in the Compute Extensibility feature spec: radius-project/design-notes#96 (comment)

AB#16674