Comments (15)
@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?
from servicebus-csharp-function-dataverse.
@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.
from servicebus-csharp-function-dataverse.
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.
from servicebus-csharp-function-dataverse.
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.
from servicebus-csharp-function-dataverse.
We will close the issue as expected behavior
.
from servicebus-csharp-function-dataverse.
@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?
from servicebus-csharp-function-dataverse.
@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.
from servicebus-csharp-function-dataverse.
@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.
from servicebus-csharp-function-dataverse.
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 theazd 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 exampleazure.yaml
- and use thegh workflow run
command of GitHub CLI to trigger the considered GitHub workflow.
from servicebus-csharp-function-dataverse.
@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.
from servicebus-csharp-function-dataverse.
@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?
from servicebus-csharp-function-dataverse.
@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:
- azd init --template rpothin/servicebus-csharp-function-dataverse
- 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?
from servicebus-csharp-function-dataverse.
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:
azd init --template rpothin/servicebus-csharp-function-dataverse
or open a GitHub Codespace directly from this GitHub repository- Run the post-init-setup.ps1 PowerShell script to finalize the configuration
- Run
azd up
to push everything to Azure - Test the solution in Azure
- 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 somegh secret set <secret name>
to add other required secrets - Push some updates in the
src
folder or theinfra
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.
from servicebus-csharp-function-dataverse.
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.
from servicebus-csharp-function-dataverse.
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 exampleazure.yaml
- and use thegh workflow run
command of GitHub CLI to trigger the considered GitHub workflow.
Have a great day.
from servicebus-csharp-function-dataverse.
Related Issues (4)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from servicebus-csharp-function-dataverse.