Overridable commands i.e., shell-script provider
Please allow shell-scripts in provider list
@atrakic can you add some more details on,
- Use-case for the same and how were you envisioning it to be used.
- Which azd commands/operations you would want that provider to act-on.
@atrakic can you add some more details on,
- Use-case for the same and how were you envisioning it to be used.
- Which azd commands/operations you would want that provider to act-on.
I have this example repo that follows azd template file structure: https://github.com/atrakic/azure-webapp-deploy. Instead of using bicep/tf providers, I would like acd to create infra, build and deploy image. Please advise. Thx
Can you give an example of what would be in the script? az cli commands?
@jongio Within the repo I have already mentioned, I have already script with az commands for creating a web app with linux container: https://github.com/atrakic/azure-webapp-deploy/blob/main/infra/setup.sh. Does this answers your question?
IC, We could potentially support this with #810 ext @wbreza is that right?
I'm curious though why you prefer to do that over bicep or terraform. With your approach you have no tear down support and it gets cumbersome to maintain. Highly recommend going iac route.
I also noticed that you have .go in your /src folder. azd doesn't yet support go apps either. @rajeshkamal5050 FYI
@jongio
IMHO, I find az cli as cleanest, lightest, easy to follow route to create infra resources without installing extra libs, sdks, etc, so Im really interested in having this feature buildt in acd.
Also, as per tear down: you have a point there, but this can be solved by exporting command instructions (after infra deployment) in tmp file which can be used for later destroy phase - aka terraform local state. What do you think about this?
I was not aware of go apps are not supported, thx for letting me know. Any plans for the future?
May be another extensibility use-case for script-based provisioning. How to leverage existing scripts (invokes Az CLI commands, direct REST API's etc.) for provisioning i.e., not using IaC(Bicep, Terraform). The pre and post hooks assume the provisioning is done via our IaC(Bicep/Terraform).
I have also thought about this. Having script support for IaC providers would also support transitional scenarios where a team may have existing legacy script based deployment system with plans to migrate to bicep/terraform.
I could see this going one of 2 ways.
- New script based IaC provider where the dev would need to provide the
upanddownscripts - Azd extensibility route where you dev overrides the whole
provision/infra createcommand with a custom script
I believe the latter would be more extensible scenario and solve additional use cases.