Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/karlospn/tf-azuredevops-pipelines-provisioner
This repository contains a Terraform provider to create builds on classic mode with Azure DevOps. It creates opinionated builds based on a few parameters.
https://github.com/karlospn/tf-azuredevops-pipelines-provisioner
azure-devops golang
Last synced: 3 months ago
JSON representation
This repository contains a Terraform provider to create builds on classic mode with Azure DevOps. It creates opinionated builds based on a few parameters.
- Host: GitHub
- URL: https://github.com/karlospn/tf-azuredevops-pipelines-provisioner
- Owner: karlospn
- Created: 2020-05-12T12:28:20.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2023-02-14T15:58:39.000Z (over 1 year ago)
- Last Synced: 2024-06-22T18:01:05.337Z (5 months ago)
- Topics: azure-devops, golang
- Language: C#
- Homepage:
- Size: 72.3 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- jimsghstars - karlospn/tf-azuredevops-pipelines-provisioner - This repository contains a Terraform provider to create builds on classic mode with Azure DevOps. It creates opinionated builds based on a few parameters. (C# #)
README
## Terraform Azure DevOps classic builds custom provider
This repository contains a provider to create builds on classic mode with Azure DevOps. It creates **opinionated builds** based on a few parameters.
The provider does not interact directly with Azure DevOps API, it uses a tailor-made NET Core 3.1 WebAPI to create the builds.
You might be asking why I'm creating an API that acts like a men-in-the-middle when I could be calling the Azure DevOps API directly from the Terraform provider. And that's because some people are afraid of Golang and that's a neat trick to minimize the Go codebase.
The custom provider delegates almost all the ETL work into the custom WebApi.
### How to create a build?
Here is an example about how to create a build:
```javascript
resource "build_definition_resource" "test" {
path = "\\Autogenerated"
project = "projectA"
application_name = "its_my_build"
build_template = "mytg"
build_template_inputs = {
"xxx" : "yyyy"
"zzz" : "ppp"
"myvar" : "somevar"
}
queue_pool = "MyHostedPool"
repository = "App1"
branch = "master"
tags = ["tag1"]
variable_groups = ["MyGroup"]
ci_triggers {
branch_filter = ["+refs/heads/master"]
}
}
```
The attributes are the following ones:
- **path**: The folder inside Azure DevOps pipelines where the buid is going to be saved.
- **project**: The Azure DevOps team project.
- **application_project**: Name of the app. It uses the name to create the name of the build.
- **build_template**: You cannot add Tasks directly to the build, you can only reference an existing Task Group. The build_template parameter is the name of the Task Group. The build isn't going to reference the task group directly, instead it will take all the tasks that the task group contains an copy them into our build.
- **build_template_inputs**: Inputs that the task group need to run.
- **queue_pool**: The agent pool where our build is going to run.
- **repository**: Repository name.
- **branch**: Branch name.
- **tags**: Tags to assign to our build
- **variable_groups**: Name of the variable_group that you want to use. It needs to exist previously.
- **ci_triggers**: Continous Integration Triggers.
- **schedule_triggers**: Scheduled Triggers.
- **variables**: Variables that the build might need.