Azure / bicep

Bicep is a declarative language for describing and deploying Azure resources
MIT License
3.21k stars 746 forks source link

Remove nondeterministic warning for Automation Job Schedule names #10340

Open jamasten opened 1 year ago

jamasten commented 1 year ago

Bicep version Bicep CLI version 0.16.1 (d77dcc750a) VSCode Extension v0.16.1

Describe the bug Receive a warning that an Automation Job Schedule name is nondeterministic.

To Reproduce Per MSFT documentation, the newGuid function must be used so Job Schedules can be idempotent.

param JobScheduleName string = newGuid()

resource jobSchedule 'Microsoft.Automation/automationAccounts/jobSchedules@2022-08-08' = {
  parent: automationAccount
  name: JobScheduleName
  properties: {
    parameters: {
    }
    runbook: {
      name: runbook.name
    }
    schedule: {
      name: schedule.name
    }
  }
}

Additional context This creates confusion during customer deliveries and causes unnecessary churn.

alex-frankel commented 1 year ago

We can't get rid of this warning because it's relevant for all other resource types. Does disabling the linter rule in bicepconfig.json resolve this? You can also disable the warning within the file like so:

resource jobSchedule 'Microsoft.Automation/automationAccounts/jobSchedules@2022-08-08' = {
  parent: automationAccount
  #disable-next-line use-stable-resource-identifiers
  name: JobScheduleName
  properties: {
    parameters: {
    }
    runbook: {
      name: runbook.name
    }
    schedule: {
      name: schedule.name
    }
  }
}
jamasten commented 1 year ago

@alex-frankel can I make a feature request for per resource type rules? Or is this ultimately a short coming with the Microsoft.Automation resource provider and should be fixed on their end? If the latter, please let me know and I'll submit feedback to the PG. Though I appreciate the information you provided above, it's still a workaround that will have to be explained during a customer delivery.

WithHolm commented 1 year ago

could this be done in another way?

perhaps to just use the guid() function when detemining the name of the jobschedule?

this takes in a array of strings and guid would be calculated from that. so output would be idempotent. i know this is heavily used when doing rbac, so why not for job schedules aswell?

jamasten commented 1 year ago

@WithHolm Automation Job Schedules documenation: image Reference

GUID function documentation: image Reference

WithHolm commented 1 year ago

Ok, I'm sorry. I thought you wanted a idempotent value, not a random value.

If that's the case you could use UTC now to generate guid

I would suggest you go with Alex's answer and add a warning override above the value. Maybe document over the resource why you are overriding this warning

jamasten commented 1 year ago

@WithHolm I don't care about the value as long as the resource deployment is idempotent. Using the newGuid function, Job Schedule deployments are idempotent. Using a timestamp with the guid function would be unique each time and should work as well. However, that creates the same nondeterministic warning in VSCode.

image

The issue with Alex's response is that every time I use an Automation Job Schedule I will have to document why I'm hiding the warning and will ultimately lead to questions about when the PG will fix it. Its churn that myself and other engineers will have to deal with since it is a shortcoming with the tool / resource provider.

@alex-frankel please let me know if I should make a Bicep feature request or submit feedback to the PG for the resource provider. Thanks!

alex-frankel commented 1 year ago

I think we could have a bicep feature request like "exempt linter rules for specific resource types", but not sure how open the team will be to that. Still worth filing (or re-purposing this issue)

It's also worth sharing with the Automation PG to discuss if there are other ways to model this resource such that you can create unique jobs without having to create a new resource every time.