Add Stripe CLI hosting integration

[Copilot]

Implementation Complete: Stripe CLI Hosting Integration

Successfully implemented a complete hosting integration for the Stripe CLI in the .NET Aspire Community Toolkit.

✅ All Tasks Completed

• Integration Package (src/CommunityToolkit.Aspire.Hosting.Stripe/)

  • Project file with proper package metadata and tags
  • StripeResource - ContainerResource for Stripe CLI
  • StripeExtensions - Comprehensive extension methods
  • Complete README with correct API usage examples
  • Fixed documentation for events parameter to reflect IEnumerable

• Test Package (tests/CommunityToolkit.Aspire.Hosting.Stripe.Tests/)

  • Unit tests covering all extension methods
  • Integration tests for the example AppHost
  • Added to CI workflow

• Example Application (examples/stripe/)

  • AppHost project demonstrating webhook forwarding
  • Sample API project with webhook endpoint
  • All projects added to solution file

• Code Quality Improvements

  • Fixed README examples to use ExternalService instead of plain strings
  • Updated events parameter documentation to clarify array syntax
  • Added explicit Where filters to foreach loops per code review

Recent Fixes (Latest Commit)

• Fixed README examples on lines 84-86 and 97 to use AddExternalService instead of plain string URLs
• Updated events parameter in examples from comma-separated string to array syntax: ["event1", "event2"]
• Corrected XML documentation for events parameter from "comma-separated list" to "collection"
• Added explicit Where filters to foreach loops in StripeExtensions.cs and RequiresAuthenticatedToolDiscoverer.cs

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Hosting integration for Stripe CLI</issue_title>
<issue_description>### Related to an existing integration?

No

Existing integration

No response

Overview

It would be a valuable addition to the Aspire ecosystem to include a built-in integration for the Stripe CLI. When working locally, the Stripe CLI is essential for simulating webhooks, managing test data, and interacting with the Stripe API in real time. Embedding this functionality into Aspire as a hosting extension would streamline the developer experience by reducing manual setup and enabling better orchestration of services. This could significantly improve productivity and consistency across environments, especially for teams building payment-enabled applications. A native Aspire extension for Stripe CLI would align well with Aspire’s goal of simplifying cloud-native development through composable and observable service models.

Usage example

var stripe = builder.AddStripeLocal("stripe")...

var api = builder.AddProject<Projects.API>("api")
                   .WithReference(stripe);

Extra: commands on the resource to trigger sample requests.

Breaking change?

I'm not sure

Alternatives

$ stripe listen --forward-to http://localhost:5082/payments/stripe-webhook

Additional context

There's an article that touches the topic by @julioct

https://juliocasal.com/blog/how-to-build-custom-net-aspire-hosting-extensions-with-stripe-cli-example
https://juliocasal.com/blog/speed-up-your-stripe-dev-loop-with-net-aspire

I could help implementing this solution but I wouldn't be able to deviate too much from the blog post.

Help us help you

No, just wanted to propose this</issue_description>

Comments on the Issue (you are @copilot in this section)

Custom agent used: Hosting Integration Creator
This agent helps users create new hosting integration in Aspire by scaffolding the correct projects and files based on user input.

• Fixes Hosting integration for Stripe CLI #931

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[aaronpowell]

@Kralizek @julioct I've finally got back to this after the latest release. What do you think of the approach? It's using the installed executable not the container version, or do you think that would be a better option?

[Kralizek]

Is there a specific advantage on targeting the locally installed CLI rather than leveraging the existing container?

It feels like it's adding a manual step (installation of the CLI) that can be skipped altogether.

[julioct]

@Kralizek @julioct I've finally got back to this after the latest release. What do you think of the approach? It's using the installed executable not the container version, or do you think that would be a better option?

Why not use the container? As with anything Aspire-related, the whole point is that anyone can clone the repo, hit F5, and it just works.

[aaronpowell]

That's a fair point - I was trying to simplify getting the signing code, but it comes at a cost of simplicity. The branch has a rewrite that uses the container version.

[aaronpowell]

@Kralizek @julioct any additional feedback? Otherwise it's probably good to merge in.