Skip to content
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.

Sign up for GitHub

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

Update notes in the guide for project resource name #1142

Merged
merged 1 commit into from
Dec 3, 2024
Merged

Update notes in the guide for project resource name #1142

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 25 additions & 29 deletions docs/guides/repositories_in_project.md
View file
Open in desktop
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.
Loading