Add support for Azure DevOps in azd pipeline config - #693
Conversation
Co-authored-by: Hadwa Gaber <hadwaa@microsoft.com>
Co-authored-by: Hadwa Gaber <hadwaa@microsoft.com>
Co-authored-by: Hadwa Gaber <hadwaa@microsoft.com>
Co-authored-by: Hadwa Gaber <hadwaa@microsoft.com>
Co-authored-by: Hadwa Gaber <hadwaa@microsoft.com>
…o add-azdo-provider
… and test based on linting results.
* Refactor to introduce new azdo package * refactor azdo code to multiple files in azdo package * Added azdo connection test and refactored provider * Added azdo provider initial tests * added more azdo provider tests * Adding test to verify save env config in azdo provider * Updating displayed urls to aka.ms
* Adding service connection name to pipeline variables * Checking for service connection exists and also removing do push condition * Check for pipeline exists and update the name to include repo if exists. * adding provider arg and setting variables only for terraform (#46) * Set default pipeline provider to github * Adjust project creation wait time. * prompt for pat and org name if not in system env vars. * Azure DevOps name standardization * Update Azdo readme. * refactor to fix failing test Co-authored-by: Victor Vazquez <victor.vazquez@microsoft.com>
| local.StringVar(&p.manager.PipelineServicePrincipalName, "principal-name", "", "The name of the service principal to use to grant access to Azure resources as part of the pipeline.") | ||
| local.StringVar(&p.manager.PipelineRemoteName, "remote-name", "origin", "The name of the git remote to configure the pipeline to run on.") | ||
| local.StringVar(&p.manager.PipelineRoleName, "principal-role", "Contributor", "The role to assign to the service principal.") | ||
| local.StringVar(&p.manager.PipelineProvider, "provider", "github", "The pipeline provider to use (GitHub and Azdo supported).") |
There was a problem hiding this comment.
| local.StringVar(&p.manager.PipelineProvider, "provider", "github", "The pipeline provider to use (GitHub and Azdo supported).") | |
| local.StringVar(&p.manager.PipelineProvider, "provider", "github", "The pipeline provider to use (github and azdo supported).") |
| ) | ||
|
|
||
| var ( | ||
| AzDoHostName = "dev.azure.com" // hostname of the AzDo PaaS service. |
There was a problem hiding this comment.
Is this overridable for self-host situations.
There was a problem hiding this comment.
Yes, these variable are exported as part of the AzDo package and overridable. We can add helper method to make it easier, but they were built specifically with the idea that we could override to use a self host AzDo server.
After this PR I will set up a self hosted AzDo and test against that.
| AzurePipelineName = "Azure Dev Deploy" // name of the azure pipeline that will be created | ||
| AzurePipelineYamlPath = ".azdo/pipelines/azure-dev.yml" // path to the azure pipeline yaml | ||
| CloudEnvironment = "AzureCloud" // target Azure Cloud | ||
| DefaultBranch = "master" // default branch for pipeline and branch policy |
There was a problem hiding this comment.
I think this should be main right?
There was a problem hiding this comment.
Yes, we kept it as master because the original GitHub flow created a master branch. We can switch the default branch to main for both.
There was a problem hiding this comment.
Are you sure? I believe it defaults to what the developer machine has as the default and we want that default to be main.
| require.NoError(t, err) | ||
| require.NotNil(t, policyType) | ||
| require.EqualValues(t, *policyType.DisplayName, "Build") | ||
|
|
There was a problem hiding this comment.
No problem, I will remove them.
| "versioncontrol": { | ||
| "sourceControlType": "git", | ||
| }, | ||
| "processTemplate": { | ||
| "templateTypeId": processTemplateId, | ||
| }, |
There was a problem hiding this comment.
One is allower, the other is camel...consistent?
There was a problem hiding this comment.
We can make the adjustment, unfortunately this is an underlying api property. In a future PR we could create a struct with the json mapping comments instead of relying on the map object. This could be a contribution back to the go sdk for azure devops and the capabilities property.
| console.Message(ctx, fmt.Sprintf("error: the project name '%s' is already in use\n", name)) | ||
| continue // try again | ||
| } else if strings.Contains(message, "The following name is not valid") { | ||
| console.Message(ctx, fmt.Sprintf("error: the project name '%s' is not a valid Azure DevOps project Name. See https://aka.ms/azure-dev/azdo-project-naming\n", name)) |
There was a problem hiding this comment.
Make sure all akas are created and have adpteam as co-owner
There was a problem hiding this comment.
Will do, I added Rajesh as co-owner but will add adpteam.
| ) (serviceendpoint.CreateServiceEndpointArgs, error) { | ||
| endpointType := "azurerm" | ||
| endpointOwner := "library" | ||
| endpointUrl := "https://management.azure.com/" |
There was a problem hiding this comment.
Is this overridable? Does it need to be?
There was a problem hiding this comment.
Yes it should be . There's a few spots in the az cli package that is hard coded to this endpoint, but to support sovereign clouds, it should be overridable. I'll add an issue so we can address this.
Co-authored-by: Jon Gallant <2163001+jongio@users.noreply.github.com>
Repoman Generation ResultsRepoman pushed changes to remotes for the following projects: Project: todo-csharp-cosmos-sqlRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-csharp-cosmos-sql -b pr/693View Changes | Compare Changes Project: todo-csharp-sqlRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-csharp-sql -b pr/693View Changes | Compare Changes Project: todo-nodejs-mongo-acaRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-nodejs-mongo-aca -b pr/693View Changes | Compare Changes Project: todo-nodejs-mongo-swa-funcRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-nodejs-mongo-swa-func -b pr/693View Changes | Compare Changes Project: todo-nodejs-mongoRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-nodejs-mongo -b pr/693View Changes | Compare Changes Project: todo-nodejs-mongo-terraformRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-nodejs-mongo-terraform -b pr/693View Changes | Compare Changes Project: todo-python-mongo-acaRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-python-mongo-aca -b pr/693View Changes | Compare Changes Project: todo-python-mongo-swa-funcRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-python-mongo-swa-func -b pr/693View Changes | Compare Changes Project: todo-python-mongoRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-python-mongo -b pr/693View Changes | Compare Changes Project: todo-python-mongo-terraformRemote: azure-samples-stagingBranch: pr/693You can initialize this project with: azd init -t Azure-Samples/todo-python-mongo-terraform -b pr/693View Changes | Compare Changes |
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsStandalone Binary
Container |
|
Closed in favor of: #743 |
This PR fixes #101, #708, #699 and #702 and adds support for Azure DevOps an SCM and CI provider.
This new workflow enables the following:
Pipeline named providers for GitHub
githuband Azure DevOpsazdoThe provider can be specified in two ways:
Detection of provider based on .azdo or .github in the template augments the above behavior.
githubifazdois set as a provider value, this will result in an errorazdo. Ifgithubis set as the provider value, this will result in an error.AzDo provider supports using an existing project.
AzDo provider supports creating a new project.
AzDo provider supports using an existing repo.
AzDo provider supports creating a new repo in a project.
PAT authentication is used to push to the new repo, and the tool checks for credential helper and offers to set it to store to make subsequent pushes easier.
If a PAT is not provided, the tool will ask the user for a PAT and ask the user if they would like to store it.
If an organization name is not provided via an Environment Variable, the user will be prompted for an organization name and it will be stored in the environment file.
AzDo provider creates a build policy to ensure pushes to default branch are disabled and require a successful pipeline invocation.
Deployment Pipeline is created
Service Connection is created to allow the pipeline to deploy to azure.
Initial pipeline deployment is queued to follow the github behavior.
This was tested with a full deployment of todo-python-mongo using an Azure DevOps Pipeline.
