Allow full_path in addition to id in gitlab_project data source

[sirlatrom]

Fixes #140.

[armsnyder]

Thanks for the contribution. A better fix would be to change the type for id into string in the resource schema (this is a backward compatible change) and update the documentation to mention that id can be an int or string. I don't think full_path is the standard name for this field in the GitLab API, nor is it used anywhere else in this plugin.

[sirlatrom]

Thanks for the contribution. A better fix would be to change the type for id into string in the resource schema (this is a backward compatible change) and update the documentation to mention that id can be an int or string. I don't think full_path is the standard name for this field in the GitLab API, nor is it used anywhere else in this plugin.

It's used here:

terraform-provider-gitlab/gitlab/data_source_gitlab_group.go

Lines 23 to 30 in f821d59

	"full_path": {
	Type: schema.TypeString,
	Computed: true,
	Optional: true,
	ConflictsWith: []string{
	"group_id",
	},
	},

which is what I took as inspiration.

[armsnyder]

It's used here:

terraform-provider-gitlab/gitlab/data_source_gitlab_group.go

Lines 23 to 30 in f821d59

	"full_path": {
	Type: schema.TypeString,
	Computed: true,
	Optional: true,
	ConflictsWith: []string{
	"group_id",
	},
	},

which is what I took as inspiration.

Ahh, good point. However, I would still rather stick to the official GitLab API field names, as I see this as API debt.

See the API fields names for GET Project: https://docs.gitlab.com/ee/api/projects.html#get-single-project

See the HashiCorp guidance on this subject: https://www.terraform.io/docs/extend/hashicorp-provider-design-principles.html#resource-and-attribute-schema-should-closely-match-the-underlying-api

[sirlatrom]

Ahh, good point. However, I would still rather stick to the official GitLab API field names, as I see this as API debt.

See the API fields names for GET Project: https://docs.gitlab.com/ee/api/projects.html#get-single-project

See the HashiCorp guidance on this subject: https://www.terraform.io/docs/extend/hashicorp-provider-design-principles.html#resource-and-attribute-schema-should-closely-match-the-underlying-api

OK, I'll change the type of id, but are you quite sure you can go from a TypeInt to TypeString without state parsing issues? I'll give it a try.

[armsnyder]

OK, I'll change the type of id, but are you quite sure you can go from a TypeInt to TypeString without state parsing issues? I'll give it a try.

Yep, going from int -> string is fine. Terraform will update the type in the state on the next apply, and users can even continue to set this field to a number in their config.

[sirlatrom]

Yep, going from int -> string is fine. Terraform will update the type in the state on the next apply, and users can even continue to set this field to a number in their config.

@armsnyder Done in 55a5f54.

[armsnyder]

Great! One final note.

[armsnyder]

Thanks!