New Resource: gitlab_project_issue_board

[timofurrer]

This PR introduces the new resource gitlab_project_issue_board (as requested in #772).
A simple example may look like this:

resource "gitlab_project_issue_board" "this" {
  project = gitlab_project.example.id
  name    = "Test Issue Board"

  lists {
    label_id = 1
  }

  lists {
    assignee_id = 1
  }

  lists {
    milestone_id = 1
  }
}

This resource is (probably) the first one where I've decided to go with sub resources - the lists instead of having a separate resource gitlab_project_issue_board_list. I decided to go with this approach to make it easier to have consistent positioning of the lists - which is taken care of by the resource itself based on the position the list appears in the attribute lists in the config.
However, this makes implementation a little bit "unusual" and even "cumbersome" because nested Schemas are not very well supported, e.g. features like ExactlyOneOf or ConflictsWith are simply not supported. There is also only one CRUD trigger for the main resource, thus the lists have to be handled there - more or less manually. In the board lists case this is not to dramatic, because we just create the list in the create hook (surprise 😛 ) and just delete and recreated the lists in case there was a change in the config of the lists attribute. The deletion doesn't matter, because if the board gets deleted, the lists are deleted.

Another decision point was the naming of the attribute lists. The above example screams for the attribute to be named lists. BUT, I foresee that people want to create standardized boards in projects, thus they most likely want to use it like this:

resource "gitlab_project_issue_board" "this" {
  project = gitlab_project.example.id
  name    = "Test Issue Board"

  lists = var.board_lists
}

... where var.board_lists is a standard set of lists. They may also use for_each for which it would be an unfortunate naming again. There are no aliasing, so we couldn't do that.
What we could do, is duplicate the lists attribute to a list attribute and mark it was ConflictsWith: <the other one>.

@PatrickRice-KSC @armsnyder any thoughts on this? Ideas?

This PR is currently blocked by:

• Update Project Issue Board API to match upstream API xanzy/go-gitlab#1504

Closes: #772

[timofurrer]

Actually, by now I'm preferring list over lists - one could still use variables, maybe using also dynamic.

WDYT?

[PatrickRice-KSC]

@timofurrer - Sorry for the delay in responding to this! It seems like the lists attribute might be better as a map as opposed to a sub-resource? That way, as you mention in the description, people could create a standardized set of columns and apply it across projects, and it meshes the with CRUD operations in Terraform a bit better. That way you could do something like this:

resource "gitlab_project_issue_board" "this" {
  project = gitlab_project.example.id
  name    = "Test Issue Board"

  lists = {
    list_one : {
      label_id: "1"
    },
    list_two : {
      assignee_id: "2"
    }
  }
}

While it would get a bit messy if you had a massive board, this would allow you to keep the configurations within one resource, AND make it a variable if you wanted to.

[timofurrer]

@PatrickRice-KSC hmmm, can you elaborate?

What you suggested is currently possible using the following syntax:

resource "gitlab_project_issue_board" "this" {
  project = gitlab_project.example.id
  name    = "Test Issue Board"

  lists = [
    {
        label_id: "1"
    },
    {
        assignee_id: "2"
    }
  ]
}

... that is, because the block syntax is just syntactic sugar for the aforementioned example. You may as well now store the lists in a variable and use it for standardization:

resource "gitlab_project_issue_board" "this" {
  project = gitlab_project.example.id
  name    = "Test Issue Board"

  lists = var.std_board_list
}

WDYT? 🏓

[PatrickRice-KSC]

What you suggested is currently possible using the following syntax:

@timofurrer - I honestly didn't realize you could pass in multiple nested blocks using a list syntax, that's a bit embarrassing. TIL. Makes sense to me!

[PatrickRice-KSC]

Looks good to me! 🚢

[github-actions]

This functionality has been released in v3.17.0 of the Terraform GitLab Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue. Thank you!