Open sk593 opened 1 month ago
:wave: @sk593 Thanks for filing this issue.
A project maintainer will review this issue and get back to you soon.
We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.
For more information on our triage process please visit our triage overview
:+1: We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.
We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.
For more information on our triage process please visit our triage overview
Area for Improvement
We've discussed moving the
hack/bicep-types-radius
type generator to it's own repository and consuming that repo as a submodule [referred to asradius-generator
in this issue]. We should investigate whether this is the right approach and the steps needed to make this compatible with the main Radius repository. There might also be some overlap between this and UDTs so we should also investigate if the work should be done together.An alternative option is to rename the folder if we decide not to move this to a separate repo.
Observed behavior
No response
Desired behavior
This would work similar to how we generate AWS types now in the
bicep-types-aws
repository. We'd have a separate repository for theradius-generator
code and then use the repository as a submodule to generate types in the main Radius repo.This removes the dependency on the
bicep-types
submodules in the Radius repo. We use this submodule to help with type generation but that also means we need to keep it up to date and watch for breaking changes (this part is automated through dependabot right now). Having the Radius-type generator in a separate repo would decouple the main Radius repo and the dependent submodule.Things to consider:
make generate
script to initialize and pull from the new radius generator submoduleradius-generator
as a submodule when runningmake generate
, during workflows, etc.Proposed Fix
No response
rad Version
n/a
Operating system
No response
Additional context
No response
Would you like to support us?
AB#13442