You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently we only support integrating with a single VCS repo to manage app configs for all apps. This will likely not support the use case where each app/org has a different team managing the configs/assets.
Describe the solution you'd like
We should allow configs for an associated VCS repo to be specified in the app/org document. When a webhook request is received, it should be verified against these configurations to see if the update should be performed for that app/org. The webhook-configs.json can likely be removed if we add a new code field to each Application, AppType, and Organization to handle the mapping to folders in the repo.
Describe alternatives you've considered
The alternative is to use a single repo to manage configs for every app/org in the system. If we do this, the system admin would need to be responsible for managing these app configs, as no app or org specific admins could be given access to a limited set of these configs.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently we only support integrating with a single VCS repo to manage app configs for all apps. This will likely not support the use case where each app/org has a different team managing the configs/assets.
Describe the solution you'd like
We should allow configs for an associated VCS repo to be specified in the app/org document. When a webhook request is received, it should be verified against these configurations to see if the update should be performed for that app/org. The
webhook-configs.json
can likely be removed if we add a newcode
field to eachApplication
,AppType
, andOrganization
to handle the mapping to folders in the repo.Describe alternatives you've considered
The alternative is to use a single repo to manage configs for every app/org in the system. If we do this, the system admin would need to be responsible for managing these app configs, as no app or org specific admins could be given access to a limited set of these configs.
The text was updated successfully, but these errors were encountered: