Skip to content

Commit

Permalink
Merge pull request #1142 from jfrog/update-repository-project-guide
Browse files Browse the repository at this point in the history
Update notes in the guide for project resource name
  • Loading branch information
alexhung authored Dec 3, 2024
2 parents 850676d + 4c4add9 commit 0293477
Showing 1 changed file with 25 additions and 29 deletions.
54 changes: 25 additions & 29 deletions docs/guides/repositories_in_project.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,51 +7,47 @@ The guide provides information and the example on how to add repositories to the
## Artifactory behavior

The attribute `project_environments` (`environments` in the API call) is ignored by Artifactory, if the repository is not assigned to an existing project.

That attribute can only be set to the repository if it's assigned to the project already.
The project can't be created with the list of non-existing repositories, and the repository can't be assigned to non-existing project.
Thus, if the project and the repository/repositories are created at the same time in one Terraform configuration, we have a state drift
for the `project_environments` attribute.

This is happening, because the repositories need to be created first, then the project with the list of repositories gets
created. Since `project_environments` attribute is ignored in the first step, we will only have this attribute in the Terraform state, and
not in the actual repository properties.
Thus, if the project and the repository/repositories are created at the same time in one Terraform configuration, we have a state drift for the `project_environments` attribute.

On the next step, when the repo gets assigned to the project by the project resource, the default value `DEV` is assigned to
repositories' `project_environments` attribute. If the desired value on the first step was `DEV`, then the values match and no state
drift occurs. But if the desired value was `PROD`, we will get an error message when updating the config by `terraform plan`/`terraform apply`.
This is happening, because the repositories need to be created first, then the project with the list of repositories gets created. Since `project_environments` attribute is ignored in the first step, we will only have this attribute in the Terraform state, and not in the actual repository properties.

```
# artifactory_local_docker_v2_repository.docker-v2-local will be updated in-place
~ resource "artifactory_local_docker_v2_repository" "docker-v2-local" {
id = "myproj-docker-v2-local"
~ project_environments = [
- "DEV",
+ "PROD",
]
}
On the next step, when the repo gets assigned to the project by the project resource, the default value `DEV` is assigned to repositories' `project_environments` attribute. If the desired value on the first step was `DEV`, then the values match and no state drift occurs. But if the desired value was `PROD`, we will get an error message when updating the config by `terraform plan`/`terraform apply`.

```sh
# artifactory_local_docker_v2_repository.docker-v2-local will be updated in-place
~ resource "artifactory_local_docker_v2_repository" "docker-v2-local" {
id = "myproj-docker-v2-local"
~ project_environments = [
- "DEV",
+ "PROD",
]
}
```

## Workaround

~> In the Project provider documentation, we strongly recommend using the `repos` attribute to manage the list of repositories.
Do not use `project_key` attribute of the repository resource.
~> In the Project provider documentation, we strongly recommend using the `project_repository` resource to manage the list of repositories. Do not use `project_key` attribute of the repository resource.

Unfortunately, we can't fix the behavior described above right now. The workaround is simply to run `terraform apply` twice.
When the user applies the configuration second time, the repository is already assigned to the project, and `project_environments`
attribute won't be ignored.

When the user applies the configuration second time, the repository is already assigned to the project, and `project_environments` attribute won't be ignored.

## Full HCL example

```hcl
```terraform
terraform {
required_providers {
artifactory = {
source = "jfrog/artifactory"
version = "6.21.4"
version = "12.5.1"
}
project = {
source = "jfrog/project"
version = "1.1.1"
version = "1.9.1"
}
}
}
Expand Down Expand Up @@ -85,11 +81,11 @@ resource "project" "myproject" {
max_storage_in_gibibytes = 10
block_deployments_on_limit = false
email_notification = true
}
repos = ["myproj-docker-v2-local"]
depends_on = [ artifactory_local_docker_v2_repository.docker-v2-local ]
resource "project_repository" "myproject-docker-v2-local" {
project_key = project.myproject.key
key = artifactory_local_docker_v2_repository.docker-v2-local.key
}
```
~> Apply `lifecycle.ignore_changes` to `project_key` attribute, otherwise it will be removed from the repository,
which means it will be unassigned from the project on the configuration update.
~> Apply `lifecycle.ignore_changes` to `project_key` attribute, otherwise it will be removed from the repository, which means it will be unassigned from the project on the configuration update.

0 comments on commit 0293477

Please sign in to comment.