[Bug] There are manual steps for the "azd pipeline config"

[blow-hey]

Bug Description

There are manual steps for the azd pipeline config, need to manually click Run workflow to run the Actions.

Steps To Reproduce

1.Login with az login and azd login
2.Run Command azd init --template rpothin/servicebus-csharp-function-dataverse
3.Run Command .\scripts\post-init-setup.ps1
4.Run Command azd up
5.Run Command azd pipeline config --auth-type federated --principal-name <service principal name>

Expected Behavior

azd pipeline config command should automatically trigger workflows for GitHub Actions.

@rpothin for notification.

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[rpothin]

@blow-hey I have updated the GitHub configuration documentation page to clarify the steps to follow for the GitHub configuration.

Trying to run again the `` command after finalizing the configuration from GitHub Codespace give me the error below.
I think it is due to the fact that my GitHub Codespaces for this repository are configured to require GPG verification.

Do you think I should raise an issue in the Azure/azure-dev repository for this error?

[rpothin]

@blow-hey please let me know if with the latest version of the GitHub configuration documentation page you are able to complete the GitHub configuration and trigger the configured workflow.

Thank you in advance for your test.

[blow-hey]

@blow-hey please let me know if with the latest version of the GitHub configuration documentation page you are able to complete the GitHub configuration and trigger the configured workflow.

Thank you in advance for your test.

We still need to manually trigger the workflow according to the latest version of the GitHub configuration documentation page.

[rpothin]

Hi @blow-hey,

I hope you are doing well.

I have been able to do a test from a local copy of the repository and I can confirm that it did not trigger the GitHub workflow I configured.

But I have also been able to check what the azd pipeline config command do to try to trigger the GitHub workflow - an empty commit.

Unfortunately, for the reasons presented below, I don't think I will change the trigger conditions configured in the GitHub workflow of this template repository:

• If I implement trigger conditions like presented in the Azure-Samples/todo-csharp-cosmos-sql template, any push to the repository would trigger the GitHub workflow, even if I push an update on a documentation page --> it does not make sense for me
• Moreover, I don't think it is good practice to not correctly configure the trigger conditions in a GitHub workflow - in our case deploy the infrastructure and the function app source code. So only changes in these files should trigger it.

I hope you will understand my position.

Note
Improvement suggestion for the azd pipeline config command (to replace the existing empty commit): we could have a way to identify the GitHub workflow we want to trigger (for example its name) configured in a file - for example azure.yaml - and use the gh workflow run command of GitHub CLI to trigger the considered GitHub workflow.

[blow-hey]

@rpothin
About the error for your GitHub CodeSpaces, we can't help to verify the error with running command azd pipeline config --auth-type federated --principal-name <service principal name>in Codespaces, because our access policy is not enough.

[rpothin]

@blow-hey thank you for coming back to me regarding this issue.
No worries, I understand, all these different policies and configurations make this type of problem a bit difficult to investigate.

My current hypothesis about this particular point is that azd pipeline config is perhaps using the GitHub CLI to create the empty commit. But when you use it from Codespaces with GPG verification enabled you don't get the prompt where you could enter the "key" to be able to finalize the operation.
Doing the test locally I had to enter my "key" to be able to "sign" my empty commit running the azd pipeline config command. But this kind of behavior does not seem supported in Codespaces if I am not wrong...

Regarding the configuration of the triggers of the GitHub workflow, what do you think about my latest comment?

[v-xuto]

@jongio About configuring trigger conditions for GitHub workflows, Rpothin has a different view.
He insists that only changes to these files (deployment infrastructure and the function app source code) will automatically trigger workflows, trigger conditions configured in the GitHub workflow of this template repository.

But in these templates under Azure-Samples, such as todo-csharp-cosmos-sql, any push to the repository will trigger the GitHub workflow. What do you think?

[vhvb1989]

@v-xuto , there are not guidelines or rules from azd about how to set up the pipeline triggers.
The todo-templates define a generic trigger for customers to adapt the pipeline to their needs.

@rpothin , what's your plan for a flow like:

1. azd init --template rpothin/servicebus-csharp-function-dataverse
2. azd pipeline config

Are you expecting the first time to be a manual-trigger? or are you waiting until the next commit with changes to run the pipelines?

[rpothin]

Hey @vhvb1989,

Thank you for your comment.

Your question regarding the flow of work is a really good one.
Currently my plan is the following one:

1. azd init --template rpothin/servicebus-csharp-function-dataverse or open a GitHub Codespace directly from this GitHub repository
2. Run the post-init-setup.ps1 PowerShell script to finalize the configuration
3. Run azd up to push everything to Azure
4. Test the solution in Azure
5. GitHub configuration with azd pipeline config --auth-type federated --principal-name <service principal name> (without trying to trigger the GitHub workflow because it would not work) followed by some gh secret set <secret name> to add other required secrets
6. Push some updates in the src folder or the infra folder based on your own requirements - which would automatically trigger the GitHub workflow and update the Azure resource group already deployed

To be honest with you, I don't really see why I would like to run the GitHub workflow just after its configuration and just after running azd up. If I am not wrong in that case it would change nothing in Azure...

From my point of view, potential next steps regarding this topic would be:

• consider local execution of azd up for development - each developer would target a specific resource group associated to an azd env configured locally
• pushing changes in the GitHub repository (directly in the main branch or through a pull request) would trigger an updated version of the current GitHub workflow in this repository to deploy everything to a QA resource group and then a Production resource group if everything is ok in QA - in that case I would configure 2 different environments in the GitHub repository (QA and Production) with the same set of secrets for each one but with different values

I hope all this will help you understand my vision on this topic - and I hope you will not find it too different compared to your own vision 😅

Have a great day.

[v-xuto]

there are not guidelines or rules from about how to set up the pipeline triggers.
The define a generic trigger for customers to adapt the pipeline to their needs.azd``todo-templates

@vhvb1989 Got it. Because our testing requirements do not require extra manual steps, so we filed this issue.
For this template, the workflow will not be triggered automatically when the contents other than the specified configuration files are modified. Do you think this is an area for improvement? If not, we will close this issue.

[vhvb1989]

@v-xuto , correct. Based on @rpothin 's response, there's no expectation to automatically start the gh-pipeline after azd pipeline config. So, as long as this is part of the template's documentation (which I believe it is), that's fine. Yes, we can close the issue as expected behavior. Thank you for bringing this up.

[vhvb1989]

@rpothin

To be honest with you, I don't really see why I would like to run the GitHub workflow just after its configuration and just after running azd up

This is usually a way to delegate azd up to a github pipeline instead of running it locally. For example, if you are missing some dependencies locally, and you can't or don't want to install them. Or, another example is when you know that azd up takes a long time for the selected template (templates using APIM take ~1hour to provision resources in Azure). So, you might want to prevent a local network error, or any other contingency with your local machine during the process.

But, for now, there's no requirement for azd-templates about how the github or azdo pipelines are expected to work. The template-author can define the workflow yaml based on the template needs.

[vhvb1989]

I hope all this will help you understand my vision on this topic - and I hope you will not find it too different compared to your own vision

There are many ways to integrate azd as part of a dev-team. Teams can choose and decide what works best for them.

The model you describe, for instance, provides a unique resource group for each developer and allocates another resource group for QA and for PROD.

Another model could be to use two GitHub repos, one for QA/DEV and another for PROD. azd can help to create both GitHub repos and set it up each as a remote for the local git folder. For example, origin and prod.

And there could be another models. Each template can recommend in docs what could be work the best for that template, but it is not a requirement.

[rpothin]

Hi @vhvb1989,

Thank you very much for all these details.
I agree with you about the fact that each template and each team could want to handle things differently.

Currently, and if I am not wrong, the azd pipeline config generates an empty commit.
What do you think about the improvement suggestion below I proposed earlier in the thread?

Improvement suggestion for the azd pipeline config command (to replace the existing empty commit): we could have a way to identify the GitHub workflow we want to trigger (for example its name) configured in a file - for example azure.yaml - and use the gh workflow run command of GitHub CLI to trigger the considered GitHub workflow.

Have a great day.

[v-xuto]

We will close the issue as expected behavior.