New Resource - azuredevops_release_definition - #1590
Conversation
| * `artifact_source_trigger` - (Optional) One or more `artifact_source_trigger` blocks as documented below. Creates a release automatically when a new version of the linked artifact is available (continuous deployment). | ||
| * `schedule_trigger` - (Optional) One or more `schedule_trigger` blocks as documented below. Creates a release on a recurring schedule. | ||
|
|
||
| ~> **NOTE:** Only `artifact_source_trigger` and `schedule_trigger` are managed by this resource. Other trigger types configured in the Azure DevOps UI (pull request, container image, package, and source repository triggers) are preserved on update but are not managed by Terraform. |
There was a problem hiding this comment.
Why are the other triggers are not supported?
| A `variable` block supports the following: | ||
|
|
||
| * `name` - (Required) The name of the variable. | ||
| * `value` - (Optional) The value of the variable. Cannot be used together with `is_secret` / `secret_value`. | ||
| * `secret_value` - (Optional) The secret value of the variable. Used together with `is_secret = true`. This value is not returned by the API and is stored only in Terraform state. | ||
| * `is_secret` - (Optional) Whether the variable is a secret. Defaults to `false`. When `true`, set `secret_value` instead of `value`. | ||
| * `allow_override` - (Optional) Whether the variable can be overridden at release time. Defaults to `false`. |
There was a problem hiding this comment.
Can we split it into variable and secret_variable (is_secret = true) so that we can mark the value of secret variables as sensitive?
| A `definition_reference` block supports the following: | ||
|
|
||
| * `key` - (Required) The reference key. The required keys depend on `type`. For a `Build` artifact these are typically `project`, `definition`, and `defaultVersionType`. | ||
| * `id` - (Required) The ID value for the reference key. | ||
| * `name` - (Optional) The display name for the reference key. | ||
|
|
||
| ~> **NOTE:** The Azure DevOps server may enrich `definition_reference` with additional keys it computes (for example `defaultVersionBranch` or `artifactSourceDefinitionUrl`). If a subsequent plan shows a diff, add the reported keys as `definition_reference` blocks to keep the configuration stable. |
There was a problem hiding this comment.
Can you expalain more about what this block is? E.g. for the build artifact, why do we need these three blocks? Also, how does a user know which key to use for the other artifact types?
There was a problem hiding this comment.
For artifacts, there are multiple types of types that can be selected (e.g. Build, Git, TFVC, ...), all each with its own set of properties. The definition_reference block caters to this by allowing a more dynamic way of inputting these properties instead of hard coding the properties for each possible type of artifact.
The user has to first set an artifact type in the devops UI and then call vsrm.dev.azure.com/... to know the key for these blocks. I updated the documentation to have the users know the required fields for each type of artifact.
2 participants
All Submissions:
Description
This PR aims to add a new resource
azuredevops_release_definitionto the provider, which allows the user to manage the releases in the pipelines.Does this introduce a breaking change?
Test Result
Related Issue(s)
Fix #49
Other information
Might need to implement a data source for tasks, as users are required to specify
task_idin thetaskproperty, but there is no data source to get this. This leads to the user having to manually put in atask_idinstead of being able to usedata.azuredevops_task.test.idfor example.