-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add uuid
function and unit test
#63
base: main
Are you sure you want to change the base?
Conversation
Hey @cdituri 👋🏼, thank you for submitting this pull request. I’ll review it as soon as possible and get back to you. |
Signed-off-by: Bruno Schaatsbergen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Swapping out packages for google/uuid makes much sense. Thanks for taking a pass at this PR and polishing things up, @bschaatsbergen. Looks great! 🚀
Signed-off-by: Bruno Schaatsbergen <[email protected]>
Hey @cdituri, Thanks for your patience on this PR. I’ve reviewed it a few times and have been experimenting with the implementation. To move forward, I’d like to get input from a few colleagues on which UUID package we should standardize on, as we currently use a mix of HashiCorp’s go-uuid and Google’s uuid. In the meantime, could you share any specific use cases you envision for this assertion function? Understanding these could help guide our final implementation. Thanks! |
Hi @bschaatsbergen. No worries and thank you for the update. Makes sense regarding standardizing on an UUID package. Please see inline for the answer to your question:
The main use-case is to reduce the error prone repetition of validating UUIDs in native terraform core. UUIDs are ubiquitous in computing and, because of this, ExampleAny terraform provider or module which requires a UUID may benefit from this new function. Here's an example with AzureRM provider. Today we may validate Azure Resource IDs variables expected to be supplied as inputs using terraform core Terraform code-listing:terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
required_version = "~> 1.9"
}
variable "tenant_id" {
type = string
description = "The tenant id for some cross-tenant resource"
validation {
condition = can(regex("[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}", var.application_object_id))
error_message = "Invalid tenant id"
}
}
variable "subscription_id" {
type = string
description = "The subscription associated with some resource's deployment"
validation {
condition = can(regex("[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}", var.application_object_id))
error_message = "Invalid subscription id"
}
}
variable "application_object_id" {
type = string
description = "The object id of the Azure Entra App Registration to associate to xyz"
validation {
condition = can(regex("[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}", var.application_object_id))
error_message = "Invalid app registration object id"
}
}
provider "azurerm" {
subscription_id = var.subscription_id
features { }
}
# do more stuff and much things :) Note: Microsoft, generally, uses GUIDs. GUIDs and UUIDs share the same string representation but differ in byte-order representation. For the purposes of discussion, I'm referring to both as UUIDs. One can imagine any number of additional scenarios where this kind of validation is useful: from libvirt domain uuid validation to Azure Tenant ID validation to something as bespoke as Cisco UCS UUID Pool ID validation. Due to the ubiquity of UUIDs, the possibilities are endless. |
Adds a
provider::assert::uuid()
function to use in assertions 🚀 Cheers