What is the expected way to define parent/child relationships when authoring extensions #17332
              
                Unanswered
              
          
                  
                    
                      GABRIELNGBTUC
                    
                  
                
                  asked this question in
                Q&A
              
            Replies: 0 comments
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, child extension resources only support a subset of the features that native bicep resources do.
Imagine you are authoring a bicep extension to interface with an Azure DevOps service connection. You will have 3 layers in that hierarchy:
OrganizationOrganization/ProjectOrganization/Project/ServiceconnectionTo interact with that service connection, you will have to write your resources in one of two ways:
First:
Second:
As you can see, you are forced to always bring a
parentproperty (or something similar) with your types in order to be to communicate the hierarchy to the extension host.This is why I would like to know:
Example:
{ "resource": { "type": "Organization/Project/ServiceConnection", "apiVersion": "", "properties": {...}, "config": {}, "parent": { "type": "Organization/Project", "identifiers": {...}, "parent": { "type": "Organization", "identifiers": {...} } } } }Where extension authors would be responsible to retrieve the parent properties in their handlers.
Beta Was this translation helpful? Give feedback.
All reactions