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.

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

resource/gitlab_branch_protection: fix issue claiming that no valid access level can be found. Closes #890 #892

Merged
merged 1 commit into from Feb 24, 2022

Conversation

timofurrer
Copy link
Member

@timofurrer timofurrer commented Feb 24, 2022

I don't really understand yet what happens here. However, that behavior
changed from v3.9.1 to v3.10.0. Thus, I'm simply reverting it back.

We've had a brief exchange about this already when the "broken" code was
merged here: #881 (comment)

Obviously, we made the wrong call in that this situation doesn't
happen ... well, it happened.

Looking at the gitlab_branch_protection resource I find that it's
kinda unclear what's going on, also looking at the upstream API docs
doesn't shed any lights on this as the documentation is quite sparse.
Some of this was lately raised by @beekeep in
https://github.com/gitlabhq/terraform-provider-gitlab/issues/878#issuecomment-1048902570
, that is that some fields are arguments in the provider, but optional
in the upstream API. Also the implemented logic to retrieve the set
push_access_level and merge_access_level can only be guessed when
trying to understand how those values come to be from a POST to a
GET request of the Protected Branches
API
.

Closes #890

Description

PR Checklist Acknowledgement

  • I acknowledge that all of the following items are true, where applicable:
    • Resource attributes match 1:1 the names and structure of the API resource in the GitLab API documentation.
    • Examples are updated with:
      • A *.tf file for the resource/s with at least one usage example
      • A *.sh file for the resource/s with an import example (if applicable)
    • New resources have at minimum a basic test with three steps:
      • Create the resource
      • Update the attributes
      • Import the resource
    • No new //lintignore comments were copied from existing code. (Linter rules are meant to be enforced on new code.)

@timofurrer timofurrer added this to the v3.10.1 milestone Feb 24, 2022
@timofurrer timofurrer self-assigned this Feb 24, 2022
…ccess level can be found. Closes #890

I don't really understand yet what happens here. However, that behavior
changed from v3.9.1 to v3.10.0. Thus, I'm simply reverting it back.

We've had a brief exchange about this already when the "broken" code was
merged here: gitlabhq#881 (comment)

Obviously, we made the wrong call in that this situation doesn't
happen ... well, it happened.

Looking at the `gitlab_branch_protection` resource I find that it's
kinda unclear what's going on, also looking at the upstream API docs
doesn't shed any lights on this as the documentation is quite sparse.
Some of this was lately raised by @beekeep in
https://github.com/gitlabhq/terraform-provider-gitlab/issues/878#issuecomment-1048902570
, that is that some fields are arguments in the provider, but optional
in the upstream API. Also the implemented logic to retrieve the set
`push_access_level` and `merge_access_level` can only be guessed when
trying to understand how those values come to be from a `POST` to a
`GET` request of the [Protected Branches
API](https://docs.gitlab.com/ee/api/protected_branches.html).

Closes #890
@timofurrer timofurrer merged commit aa077bc into gitlabhq:main Feb 24, 2022
@@ -1,3 +1,9 @@
## 3.10.0 (2022-02-24)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## 3.10.0 (2022-02-24)
## 3.10.1 (2022-02-24)

@github-actions
Copy link

This functionality has been released in v3.10.1 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!

@github-actions github-actions bot locked and limited conversation to collaborators Nov 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
3 participants