uppercased key names cause failure at apply stage (should be caught at plan stage)

[edgetools]

Describe the bug

This example is slightly contrived, but I was using a random string generator for integration tests against artifactory repo creation and discovered that the provider doesn't validate the key for lowercase at the plan stage.

error:

╷
│ Error: Unable to Create Resource
│ 
│   with artifactory_remote_docker_repository.foo["foo-36UkAByD"],
│   on artifactory.tf line 1, in resource "artifactory_remote_docker_repository" "foo":
│    1: resource "artifactory_remote_docker_repository" "foo" {
│ 
│ An unexpected error occurred while creating the resource update request.
│ Please report this issue to the provider developers.
│ 
│ Error: Docker Repository foo-36UkAByD key
│ must be in lower case
╵

example snippet:

resource "artifactory_remote_docker_repository" "foo" {
  key = "foo-36UkAByD"

  url = "https://example.com"
}

/artifactory/api/system/version:

  "version" : "7.77.16",
  "revision" : "77716900",

terraform version:

> terraform version
Terraform v1.14.0
on darwin_arm64

provider version:

- Installing jfrog/artifactory v12.11.0...

License: Enterprise... I think 😅

Self-Hosted: Yes

Requirements for and issue

• A description of the bug
• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue). If this is not supplied, this issue will likely be closed without any effort expended.
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform
• Your version of terraform provider
• Your product license (E+/E/Pro/oss)
• Is your Artifactory Cloud or Self-Hosted
• [N/A] JFrog support reference (if already raised with support team)

Expected behavior

The key name is validated at the plan stage.

Additional context
N/A

[rhoades-brown]

Hi. I would like to jump on-board with this issue too. I came here to raise an issue about general repository key validation. We had somebody try and create a repository ending in -cache which is not allowed.

I was surprised to find that this succeeds the plan and fails the apply phase. It turns out that https://jfrog.com/help/r/jfrog-artifactory-documentation/repository-naming-rules-and-limitations details all of the limitations. It seems that the provider should account for these validations.

Further, I would suggest that it tests that the repository does not already exist as that can also cause a failure. I am happy to raise this as a new card, but it seems that the casing issue is just another example of the broader no-validations issue,