Enabling partner/community templates contribution

[rajeshkamal5050]

Enabling partner/community contributions. Contributors could be,

• Other DevDiv teams ex: SDK teams wanting to author new templates for demonstrating samples.
• Partner/Service teams ex: Service Connector, Open AI, APIM teams wanting to author new templates for demonstrating service/product features.
• External non-microsoft folks wanting to contribute templates.

What scaffolding code, projects, validation tools, testing tools/frameworks, system, and pipelines etc. we need to build for enabling them for an easier development, validation, testing, reviewing and publishing of templates.

Since, we already ship default TODO templates with azd and have done all of the above.

• Let us not custom build specifically for our external users.
• Let us try to expose/leverage them to the partner/community.
• Let us try to bake things into azd product/core itself ex: if the above warrants a new azd validate/test command, using above as requirements for fastening fingerprinting into azd that could help in scaffolding templates, refining azdevify process/manual-guidance.

@savannahostrowski @weikanglim @jongio @puicchan please feel free to edit/update.

[rajeshkamal5050]

Other issues around this area,

• https://github.com/Azure/azure-dev/issues/418
• https://github.com/Azure/azure-dev/issues/677
• https://github.com/Azure/azure-dev/issues/676
• https://github.com/Azure/azure-dev/issues/661
• https://github.com/Azure/azure-dev/issues/1044

[weikanglim]

Development

azd init with empty should provide a good-enough starting point for developing a template / azdevifying an existing sample. This includes creation of infra folder and having files with code comments that help describe what is expected, with a link to the official docs for more in-depth topics.

783 and #253

Still room for improvement for templates to introduce concepts of azd.

Validation

We want #1044 that provides static lint analysis for templates. The validation should also generate a report card that can be used at awesome-azd submission time as a self-attestation.

• Markdown lint for README

Testing

We probably want to encourage all templates to include CI/CD for testing the template itself. This includes two parts:

1. Documenting what that might look like (azd provision + deploy with smoke tests)
2. Adding a template ignore file for avoiding CI / scripts for validating the template to be included in the repository creating. Unfortunately, it looks like GitHub templates don't support an ignore file: https://github.com/orgs/community/discussions/22183

Reviewing

If we can implement CI/CD, the checklist would include the successful run + static lint analysis as initial proof. We still want an awesome-azd admin to deploy the template and review the template itself.

Publishing

We want to start surfacing awesome-azd templates in the CLI. Various ways to do this: which long-term with explosion could look like an actual database, but for starters, we could simply have a template list generated from awesome-azd which azd fetches and caches, or consumes at build-time as we do currently.

[savannahostrowski]

This all looks great. Thanks for digging in here.

Sort of a bummer that there's no template ignore file. I sort of worry about it being a bit confusing if we have artifacts that aren't relevant to the end user included in the templates. Perhaps we could introduce a new directory to the template structure called validation/ or authoring/ or similar and bucket all the files relevant to template creation/testing/validation under there to mitigate the risk of that. We could include a README in that dir that outlines what specifically is in here and why it's included.

Re. publishing, one idea that I had was to get set up with the experimentation framework and run an A/B experiment on azd template show that pulls in the templates as you describe (via some snapshot of awesome-azd; would also be neat to support fuzzy matching for template name searching but that's a different feature request :D) and see how that fares.

[savannahostrowski]

@rajeshkamal5050 When do you think we can continue this investigation/move forward with some of what Wei proposes here?

[rajeshkamal5050]

Moving to Gallium cc @savannahostrowski

[savannahostrowski]

I think that we have a good start here and I don't think this is as necessary at this time, as may it was several months ago (e.g. with fingerprinting etc. in the works).

I'd propose deprioritizing this in light of other efforts that I think are bigger value add. If we get concrete feedback then we can revisit reprioritizing this.