[Feature request] Add `manual` or `workflow_dispatch` flag to hooks to allow for selective execution of hooks

[john0isaac]

There is a command to run hooks manually azd hooks run <name> [flag].

But there is no flag in the hooks configuration to specify a hook to not run during the service lifecycle. Some of the hooks can only be ran once if you run the hook more than one time it will error.

My proposal is to have a workflow_dispatch flag just like GitHub actions to allow for manual trigger of the hook using the command azd hooks run

It'd be even better if you had a command like when from GitLab workflows. Possible options for when are:

• on_success (default): Run the job only when no jobs in earlier stages fail or have allow_failure: true.
• on_failure: Run the job only when at least one job in an earlier stage fails. A job in an earlier stage with allow_failure: true is always considered successful.
• never: Don’t run the job regardless of the status of jobs in earlier stages. Can only be used in a rules section or workflow: rules.
• always: Run the job regardless of the status of jobs in earlier stages. Can also be used in workflow:rules.
• manual: Run the job only when triggered manually.
• delayed: Delay the execution of a job for a specified duration.

to allow for further customizations but it would be good start if we only had a workflow_dispatch flag

[ellismg]

to allow for further customizations but it would be good start if we only had a workflow_dispatch flag

If these hooks are not tied to the service lifecycle, is the value here that azd hook run just runs a shell script with the values from the .env file injected into the process environment?

I'm wondering, if instead of forcing folks to write stuff in azure.yaml under a workflow_dispatch thing is what we want, or if there should be something like azd env run or something that runs a command or script with the .env files injected? That would also allow you to do something like azd env run bash to get a shell with all the values configured.

[john0isaac]

workflow_dispatch is just an example of what I meant but I didn't mean it in the way you understood it, this example will simplify this.

Old hooks

name: azure-search-openai-demo
metadata:
  template: [email protected]
services:
  backend:
    project: ./app/backend
    language: py
    host: appservice
hooks:
  postprovision:
    windows: # Run referenced script that uses environment variables (script shown below)
      shell: pwsh
      run: ./scripts/prepdocs.ps1
      interactive: true
      continueOnError: false
    posix:
      shell: sh
      run: ./scripts/prepdocs.sh
      interactive: true
      continueOnError: false
  postdeploy: # Pull environment variable inline from local device and set in .env file
      shell: sh
      run: azd env set REACT_APP_WEB_BASE_URL ${SERVICE_WEB_ENDPOINT_URL}
     

New hooks

name: azure-search-openai-demo
metadata:
  template: [email protected]
services:
  backend:
    project: ./app/backend
    language: py
    host: appservice
hooks:
  postprovision:
    windows: # Run referenced script that uses environment variables (script shown below)
      shell: pwsh
      run: ./scripts/prepdocs.ps1
      interactive: true
      continueOnError: false
      manual: true       # NEW
    posix:
      shell: sh
      run: ./scripts/prepdocs.sh
      interactive: true
      continueOnError: false
      manual: true      #NEW
  postdeploy: # Pull environment variable inline from local device and set in .env file
      shell: sh
      run: azd env set REACT_APP_WEB_BASE_URL ${SERVICE_WEB_ENDPOINT_URL}
     

Just a flag to stop the hook from automatically running. It should get it's env vars from azd env.

What you're suggesting is a great feature it maybe a great addition to azd in the future the env vars always bugs me. But my request is very simple, just allow me to run the hook manually using azd environment.

For example, a hook that adds data to a database may only run once if you run it multiple times it will error. So if I do azd up with the current implementation it will error as it might be in the postprovision stage.

[jongio]

If the hook is manual, then why is it associated with an action? Why should it be under postprovision if it is always manual?

[john0isaac]

Because that's the stage that it should be ran at as it needs the resources to be created and it needs to be executed before deploying the solution. (for example adding the data at azure-search-openai-demo) The only issue is that some hooks can be ran only once, that's why I wanted the manual flag to control this. So, if I set it to false it will run like it normally does but then after the first run I may set it to true to stop the hook from executing and erroring.

[jongio]

Okay, thanks for the clarification. @wbreza is the hooks original author so he should chime in.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity in the last year!!, and it will be closed in 30 days if no further activity occurs.

If you think this is a mistake, please comment on this issue to keep it open.

[vhvb1989]

Because that's the stage that it should be ran at as it needs the resources to be created and it needs to be executed before deploying the solution. (for example adding the data at azure-search-openai-demo) The only issue is that some hooks can be ran only once, that's why I wanted the manual flag to control this. So, if I set it to false it will run like it normally does but then after the first run I may set it to true to stop the hook from executing and erroring.

You should be able to create your own logic to disable hooks. For example:

• Make your hook implementation to start by querying an env var like "HOOK_NAME_DISABLE"
• If it is true, skip running the hook (return success error code)
• If it is false, run que hook normally.
• Then, at the end of the hook, if it was successful, run azd env set HOOK_NAME_DISABLE true to prevent running it again.

This will help you define your own logic for disabling specific hooks.

As of today, azd supports multiple hook-definitions for each hook type. For example, you can define a list of hook-definition for postprovision which will run one after each other. Since there is not a name to identify each hook-definitiion, we don't have (right now) a way to create a convention around disabling specific hook-definitions from running.
We could create a convention around setting an env var like AZD_HOOKS_<TYPE>_DISABLE=true which would apply to all the hook-definitions for a type, like AZD_HOOKS_PREPROVISION_DISABLE=true. But it feels like an edge case for some very specific kinds of hook-defintions (like the one you mentioned for DB setup). So I am inclined to expect template-owners to defines their own control-logic to auto-disable those kind of hooks.

I am going to close this issue after this explanation. @john0isaac feel free to re-open if you want to continue the conversation