`gitlab_repository_file` returns an error when `file_path` contains `./`

[phoban01]

GitLab Provider version

3.14.0

GitLab version

GitLab Enterprise Edition 15.0.0-pre 83043afc0a9

Terraform version

v1.1.7

Relevant Terraform Configuration

terraform {
  required_providers {
    gitlab = {
      source  = "gitlabhq/gitlab"
      version = ">= 3.14.0"
    }
  }
}

resource "gitlab_project" "main" {
  name                   = "test-repo"
  visibility_level       = "private"
  initialize_with_readme = true
}

resource "gitlab_repository_file" "foo" {
  project        = gitlab_project.main.id
  file_path      = "a/foo.txt"
  content        = "This is some text"
  branch         = "main"
  commit_message = "updated by Terraform"
}

resource "gitlab_repository_file" "bar" {
  project        = gitlab_project.main.id
  file_path      = "./a/bar.txt"
  content        = "This is some text"
  branch         = "main"
  commit_message = "updated by Terraform"
}

Relevant log output

╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to gitlab_repository_file.bar, provider
│ "provider[\"registry.terraform.io/gitlabhq/gitlab\"]" produced an unexpected new value: Root resource was
│ present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Description

The provider returns an error whenever the file_path begins with a period ./.

The file is created in GitLab despite the error.

I believe the provider should be able to handle file paths starting with ./ as this is a common notation to indicate root directory.

[timofurrer]

@phoban01 Thanks for the bug report and the reproducible example.

Quickly looking at this the problem is that when querying the GitLab API for a single file leading with a ./ it returns a 404 leading the provider to remove the resource from state resulting in the error you are seeing.

---[ REQUEST ]---------------------------------------
GET /api/v4/projects/63/repository/files/%2E%2Fa%2Ffoo%2Etxt?ref=main HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Terraform/1.1.9 (+https://www.terraform.io) Terraform-Plugin-SDK/2.10.1 terraform-provider-gitlab/dev
Accept: application/json
Authorization: Bearer ACCTEST1234567890123
Accept-Encoding: gzip


-----------------------------------------------------
2022/05/13 12:20:30 [DEBUG] GitLab API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/1.1 404 Not Found
Content-Length: 32
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json
Date: Fri, 13 May 2022 10:20:30 GMT
Server: nginx
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 01G2YEY98ECEDVMY76QR10MW7C
X-Runtime: 0.033538

{
 "message": "404 File Not Found"
}
-----------------------------------------------------
2022/05/13 12:20:30 [WARN] file ./a/foo.txt not found, removing from state

I'll later dig into GitLab to see if that can be fixed.

The same problem actually occurs for paths like a/./foo.txt ...

[phoban01]

Thanks @timofurrer, appreciate the quick response. I can easily workaround for now by omitting the leading ./.

[Shocktrooper]

Is there a point to having the leading ./ to me that is just Linux convention when you want to execute a file and not needed when specifying the file in a git repo.

It does mention in the API that traversals and other specific things result in 400's which this is not but it is close to https://docs.gitlab.com/ee/api/repository_files.html#:~:text=If%20the%20commit,specifying%20the%20error.

[phoban01]

That is true but it's also a convention that's widely used in infra-as-code tooling to specify a path relative to the project/repo root. As a user I would not expect this syntax to throw an error.

[timofurrer]

I agree with both of you ... However, given that this is a known and deliberate constraint from GitLab API side I don't think it makes a lot of sense to add additional logic to the provider to solve this. While removing leading ./ wouldn't be too difficult to implement it would still only solve a small part of the problem and introduce a new difference between the upstream API and the provider API (which is generally not desirable).

I'll leave this open for now until this upstream issue has some outcome.