Terraform Version
Terraform v0.12.17

Feature requested
It would be great if the provider could support deployment configurations as it is documented on the API specifications.

Bitbucket API
https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/{workspace}/{repo_slug}/deployments_config

Terraform version

0.11 and 0.12

Affected resource

bitbucket_default_reviewers

Terraform configuration file

resource "bitbucket_repository" "test_repo" {
  owner = "my_username"
  name = "test-repo-default-reviewers"
}

resource "bitbucket_default_reviewers" "test_reviewers" {
  owner = "my_username"
  repository = "${bitbucket_repository.test_repo.name}"
  reviewers = [
    "my_username",
  ]
}

Steps to reproduce

terraform apply -auto-approve
terraform apply -auto-approve

Expected result

Both terraform apply commands exit successfully.

Actual result

First apply successful.

Second apply:

$ terraform apply
bitbucket_repository.test_repo: Refreshing state... [id=terraform/test-repo-default-reviewers]
bitbucket_default_reviewers.test_reviewers: Refreshing state... [id=terraform/test-repo-default-reviewers/reviewers]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # bitbucket_default_reviewers.test_reviewers must be replaced
-/+ resource "bitbucket_default_reviewers" "test_reviewers" {
      ~ id         = "terraform/test-repo-default-reviewers/reviewers" -> (known after apply)
        owner      = "terraform"
        repository = "test-repo-default-reviewers"
      ~ reviewers  = [ # forces replacement
          - "",
          + "terraform",
        ]
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

bitbucket_default_reviewers.test_reviewers: Destroying... [id=terraform/test-repo-default-reviewers/reviewers]

Error: API Error: 405 2.0/repositories/terraform/test-repo-default-reviewers/default-reviewers/ 

Analysis

BitBucket has deprecated the username field in its REST API: please see #36 for more details.

GET requests to /2.0/repositories/{username}/{repo_slug}/default-reviewers now return an empty Username field in the response.

This means that when the provider runs resourceDefaultReviewersRead to populate the value of bitbucket_default_reviewers.test_reviewers.reviewers in the local state, it ends up with a value of "" for every username.

On the next apply, this "" value is passed to the resourceDefaultReviewersDelete function, which makes a DELETE request to /2.0/repositories/terraform/test-repo-default-reviewers/default-reviewers/{username}. With an empty username, this ends up being an invalid method against a different API endpoint, i.e. /2.0/repositories/terraform/test-repo-default-reviewers/default-reviewers/.

Impact

Any config with a bitbucket_default_reviewers.reviewers attribute set will produce errors after the first terraform apply.

Recommendation

Either require the reviewers attribute to be a set of user UUIDs rather than usernames, or remove this attribute and add a new attribute reviewer_uuids. This is a breaking change.

Creating a bitbucket_repository_variable fails with API 403 error. Plan works fine

# module.test.bitbucket_repository_variable.test will be created

• resource "bitbucket_repository_variable" "test" {
  • id = (known after apply)
  • key = "test"
  • repository = "xxxx/test"
  • secured = false
  • uuid = (known after apply)
  • value = "test"
    }

Terraform Version

Terraform v0.12.21

• provider.bitbucket v1.2.0

Affected Resource(s)

bitbucket_repository_variable

Terraform Configuration Files

provider "bitbucket" {
username = "xxxxxx"
password = var.password
}

resource "bitbucket_repository_variable" "test" {
key = "test"
value = "test"
repository = bitbucket_repository.test.id
secured = false
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Expected Behavior

bitbucket repository variable created

Actual Behavior

Error: API Error: 403 2.0/repositories/xxxxxx/test/pipelines_config/variables/ Your credentials lack one or more required privilege scopes.

User has admin permissions to the repo and to the organization

Terraform Version

Terraform v0.11.13

It'd be great if we could manage merge strategies chat notifications.

Hey all,

I seem to be getting 400 status codes when accessing an existing repository that was imported to this state.

Terraform Version

Terraform v0.11.7
+ provider.aws v1.25.0
+ provider.bitbucket v1.0.0
+ provider.external v1.0.0
+ provider.local v1.1.0
+ provider.random v1.3.1
+ provider.template v1.0.0

Affected Resource(s)

Please list the resources as a list, for example:

• bitbucket_repository

Terraform Configuration Files

resource "bitbucket_repository" "project_repo" {
  owner = "myaccount"
  name = "my-project"
  project_key = "api"
  scm = "git"
  is_private = true
  fork_policy = "no_public_forks"

  lifecycle {
    prevent_destroy = true
  }
}

Debug Output

Expected Behavior

Resource was imported via terraform import bitbucket_repository.project_repo myaccount/my-project, minor updates are planned:

~ bitbucket_repository.project_repo
      has_issues:                "true" => "false"
      has_wiki:                  "true" => "false"
      language:                  "php" => ""
      project_key:               "PROJ" => "api"

Actual Behavior

Running apply produced:

Error: Error applying plan:

1 error(s) occurred:

* bitbucket_repository.project_repo: 1 error(s) occurred:

* bitbucket_repository.project_repo: API Error: 400 2.0/repositories/hamweather/aeris-api Bad request

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform import bitbucket_repository.project_repo myaccount/my-project
2. terraform apply

This seems pretty reproducible. I didn't include the debug log (cause I'm lazy), but if that's actually necessary and it's hard to reproduce I can. Thanks all.

A CamelCase named Repository can not be created because the name is used as slug and in slug CamelCase is not allowed. Also there is no possibility to provide a seperate slug.

Terraform Version

Terraform v0.10.0

Affected Resource(s)

• bitbucket_repository

Terraform Configuration Files

# Configure the Bitbucket Provider
provider "bitbucket" {
  username = "username"
  password = "password" # you can also use app passwords
}

resource "bitbucket_repository" "somerepository" {
  owner      = "team"
  name       = "SomeRepository"
  scm        = "git"
  is_private = true
}

Expected Behavior

Repository created with a CamelCase name and a valid slug

Actual Behavior

It generates an api error 'Invalid slug. Slugs must be lowercase, alphanumerical, and may also contain underscores, dashes, or dots.'

Steps to Reproduce

1. terraform apply

There aren't options to set a server URL in the provider config; I take this to mean that only BitBucket cloud is supported. Are there any plans to support BitBucket Server?

Thanks

Is this provider still maintained ?

Would be nice if the bitbucket_project resource would support importing.

There are some changes in the master without a release. Is a release planned in the near future?

Terraform Version

Terraform v0.12.24

Affected Resource(s)

bitbucket_user

Terraform Configuration Files

data "bitbucket_user" "reviewer" {
  username = "foo"
}

Expected Behavior

I would like to get UUID from foo but foo is a team user.

Actual Behavior

Error: API Error: 404 2.0/users/foo foo

That would be great to be able to use team users in the near future.

As of 29th April 2019, the username field in the Bitbucket API is deprecated:

https://developer.atlassian.com/cloud/bitbucket/bitbucket-api-changes-gdpr/#removal-of-usernames-from-user-referencing-apis

The Bitbucket Terraform Provider currently uses usernames to specify the following resource attributes in Terraform configuration:

bitbucket_respository.owner

Used in requests to the /2.0/repositories/{username} endpoint.

As of 18th June 2019, this still works.

Recommendation

Deprecate bitbucket_repository.owner with a warning and add new attribute bitbucket_repository.owner_uuid. Either owner or owner_uuid must be specified.

bitbucket_default_reviewers.owner

Used in requests to the /2.0/repositories/{username}/{repo_slug}/default-reviewers endpoint .

As of 18th June 2019, this still works.

Recommendation

Deprecate bitbucket_default_reviewers.owner with a warning and add new attribute bitbucket_default_reviewers.owner_uuid. Either owner or owner_uuid must be specified.

bitbucket_default_reviewers.reviewers

Used in requests to the /2.0/repositories/{username}/{repo_slug}/default-reviewers/{target_username} endpoint, and responses from GET /2.0/repositories/{username}/{repo_slug}/default-reviewers.

Only UUIDs, and not usernames, are returned when requesting the default reviewers.

Recommendation

Specifying default reviewers via username is now broken. See #37 for details.

bitbucket_hook.owner

Used in requests to the /2.0/repositories/{username}/{repo_slug}/hooks endpoint.

As of 18th June 2019, this still works.

Recommendation

Deprecate bitbucket_hook.owner with a warning and add new attribute bitbucket_hook.owner_uuid. Either owner or owner_uuid must be specified.

Hi,

I think there is a problem with changing the owner of an repository!

Terraform Version

0.11.1

Affected Resource(s)

• bitbucket_repository

Terraform Configuration Files

before

resource "bitbucket_repository" "testrepository" {
  owner      = "${var.repository_owner}"
  name       = "testrepository"
  slug       = "testrepository"
}
variable "repository_owner" {
  type = "string"
  default = "m3gg3r"
}

https://i.imgur.com/ERoF5Q6.png
https://i.imgur.com/AeVMfhq.png
"Tobias Lückel" equals "m3gg3r"

after

resource "bitbucket_repository" "testrepository" {
  owner      = "${var.repository_owner}"
  name       = "testrepository"
  slug       = "testrepository"
}
variable "repository_owner" {
  type = "string"
  default = "meggertestteam"
}

Terraform will perform the following actions:

  ~ bitbucket_repository.testrepository
      owner: "m3gg3r" => "meggertestteam"


Plan: 0 to add, 1 to change, 0 to destroy.

https://i.imgur.com/8Smf8is.png

Expected Behavior

The owner of the repository should be changed from 'm3gg3r' to 'meggertestteam'

Actual Behavior

Terraform adds a second repository owned by 'meggertestteam' instead of changing the owner
https://i.imgur.com/PHs5qZZ.png

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply with configuration 'before'
2. terraform apply with configuration 'after'

Hi, we use this provider to manage bitbucket repos for our Org.
This worked previously but lately when we add more repos it crashes when doing terraform plan. It seems like we reach the bitbucket api throttling limit?
For each repo we set default reviewers and 3-5 webhooks. I assume there is a request per webhook when planning/applying?

terraform -v: = 0.11.7

Panic Output

https://gist.github.com/uberspot/dddefe5842cf46305fffd58f47c93f1c#file-terraform_crash-txt

Expected Behavior

Creates one more bitbucket repository with proper webhooks etc.

Actual Behavior

Connection is refused for all modules when we run plan (after adding one extra module for one extra repo).

Steps to Reproduce

We're not sure because it is not 100% reproducible by us. If we wait long enough it might work. :/

Important Factoids

We use the bitbucket cloud api with bitbucket terraform provider.

Terraform Version

Any / all

Affected Resource(s)

Documentation section "Developing the Provider" states "To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory."
However, make bin target doesn't exist.

Expected Behavior

As per the documentation the binaries shoudl be copied to $GOPATH/bin

Actual Behavior

make: *** No rule to make target `bin'. Stop.

Steps to Reproduce

Run "make bin"

This issue was originally opened by @ksatirli as hashicorp/terraform#9529. It was migrated here as part of the provider split. The original body of the issue is below.

Hi there,

I'm running into a problem with the bitbucket_repository resource. It seems remote fields are not correctly updated, even though they are stored in the tfstate file.

This ticket is specific to fork_policy, but I've noticed similar issues with is_private and language.

Terraform Version

Terraform v0.7.7

Affected Resource(s)

• bitbucket_repository

Terraform Configuration Files

resource "bitbucket_repository" "test-repository" {
  owner = "${var.bitbucket_username}"
  name = "test-repository-3kjh4asdkj"
  is_private = "true"
  language = "other"
  fork_policy = "no_forks"
}

Note: in the above example, bitbucket_username is just the same username used to configure the provider itself.

Panic Output

no panic

Expected Behavior

The fork_policy should be set on an initial run and then only show up as changed when it actually has changed

Actual Behavior

The fork_policy shows as changed on every run.

Steps to Reproduce

1. terraform apply
2. inspect initial output:

+ bitbucket_repository.test-repository
    clone_https: "<computed>"
    clone_ssh:   "<computed>"
    fork_policy: "no_forks"
    has_issues:  "false"
    has_wiki:    "false"
    is_private:  "true"
    language:    "other"
    name:        "test-repository-3kjh4asdkj"
    owner:       "my-bitbucket-username"
    scm:         "git"

1. Another terraform apply will then show that the resource has been updated, again. This shows up as changed resource on every run.

Important Factoids

n/a

Hi there,

It would be nice to be able to set pipelines for a bunch of projects (pretty useful when a lot of repo needs AWS keys, npm token etc...).

It would be awesome because currently, this must be done manually, and could be nicely automated with Terraform (AWS SSM to inject into BP, integration test where i need to configure the endpoint, which could be easily used updated from terraform output etc.)

Terraform Version

v0.12.2

Terraform Version

0.10.7

Affected Resource(s)

• bitbucket_repository

Terraform Configuration Files

provider bitbucket {
  username = "my_username"
  password = "my_password"
}

resource bitbucket_repository "test" {
  owner = "my_team"
  name  = "test-repo"
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Actual Behavior

What actually happened?

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ bitbucket_repository.test
      project_key: "PROJ" => ""


Plan: 0 to add, 1 to change, 0 to destroy.

------------------------------------------------------------------------

Steps to Reproduce

1. terraform apply
2. terraform plan

Important Factoids

N/A

References

N/A

Terraform Version

Terraform v0.12.24

• provider.aws v2.59.0
• provider.bitbucket v1.2.0

Affected Resource(s)

• bitbucket_repository_variable
  when secured = true

Terraform Configuration Files

resource "bitbucket_repository_variable" "foo" {
  repository = bitbucket_repository.test.id
  key        = "foo"
  value      = "bar" 
 secured    = true
}

Expected Behavior

I only expect the value to be updated if it is changed, not on every apply.

Actual Behavior

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # bitbucket_repository_variable.foo will be updated in-place
  ~ resource "bitbucket_repository_variable" "foo" {
        id         = "foo"
        key        = "foo"
        repository = "baz/buzz"
        secured    = true
        uuid       = "{7948f751-9ab7-4b24-ab33-d80fbd99f9f5}"
      + value      = "bar"
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
2. terraform plan

Current Workaround

Avoid ever resetting the value, (opens the user up to a stale value):

resource "bitbucket_repository_variable" "foo" {
  repository = bitbucket_repository.test.id
  key        = "foo"
  value      = "bar" 
 secured    = true
  lifecycle {
    ignore_changes = [value]
  }
}

Feature request

Terraform Version

Terraform v0.12.17

Feature requested

Support for branch policies, the feature should allow creating a standard set of policy variants that can be applied at a per-repository/project level (if possible)

Bitbucket API

https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/branch-restrictions

Terraform Version

$ terraform version
Terraform v0.11.14
+ provider.bitbucket v1.2.0

Affected Resource(s)

Please list the resources as a list, for example:

• bitbucket_repository

Terraform Configuration Files

resource "bitbucket_repository" "my_repo" {
  owner = "my-team"
  name  = "my-repo"
}

Expected Behavior

Terraform should have imported my-repo without errors.

Actual Behavior

$ terraform import bitbucket_repository.my_repo my-team/my-repo
bitbucket_repository.my_repo: Importing from ID "my-team/my-repo"...
bitbucket_repository.my_repo: Import complete!
  Imported bitbucket_repository (ID: my-team/my-repo)
bitbucket_repository.my_repo: Refreshing state... (ID: my-team/my-repo)

Error: bitbucket_repository.my_repo (import id: my-team/my-repo): 1 error occurred:
        * import bitbucket_repository.my_repo result: my-team/my-repo: bitbucket_repository.my_repo: API Error: 404 2.0/repositories/my-team/my-repo/pipelines_config Not found

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Use the config provided above, but adjust to a team name and repo you have access to
2. terraform import bitbucket_repository.my_repo my-team/my-repo

Important Factoids

• The user I'm using has full admin access to the team and repo
• If I visit https://bitbucket.org/my-team/my-repo/addon/pipelines/home and click 'Commit file' at the bottom (thus enabling pipelines) and try the above again, the import succeeds
• Creating a repository without enabling pipelines still works ok - it appears to be just importing that is affected
• Might be a regression in #41?

This issue was originally opened by @saitheexplorer as hashicorp/terraform#14458. It was migrated here as part of the provider split. The original body of the issue is below.

Hey all - new to Terraform, really liking it so far! Thanks for building a such a great tool.

I saw that there is a Bitbucket provider to manage webhooks, but the repositories must specified. I'm still learning TF, so please correct me if I'm wrong, but if we add a BB data source of all the repositories, I'd be able to loop through those repositories and set webhooks / default reviewers, right?

If so, I can take a stab at implementing this data source.

Terraform 0.10+

Great resource, but badly needs User/Group management resource on a repository as this is one of the most fundamental aspects you want to manage.

It would be awesome if terraform-provider-bitbucket could provide functionality to manage the user/group management of the repo (not just the Owner of the repo)

Hello there,

As with other resources, the terraform destroy command destroys the resources. The documentation on https://www.terraform.io/docs/providers/bitbucket/index.html does not tell whether this provider will actually destroy the bitbucket git repository or not.

Can you fix the documentation to be clear on this subject?

Cheers,

Terraform Version

Terraform v0.12.0

Affected Resource(s)

Provider

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

provider "bitbucket" {
  password = "${var.bb_pw}"
  username = "${var.bb_user}"
}

I know you are probably already aware that v0.12 has dropped, and that your provider is no longer compatible. Is there any work being done on upgrading to v0.12 compatibility? Can you guys give a rough timeline?

Thanks a ton, your provider is great!

Terraform Version

Terraform v0.12.20

Issue

I don't see any support for pointing the bitbucket provider to a self hosted instance of bitbucket. We host our own instance, but are interested in using this to manage some of our bitbucket repos. Is there any plan to support this in the future?

Hi

Since the projects is go mode enabled there is no point of keeping vendor in the version control. Especially that we do not really want to retain backwards compatibility (as per README recommends using go 1.11)

I recommend removing vendor from git - it is mostly hygienic change. Makefile might need changes too. I can work on a PR if you are on the same page @cwood .

Hi,

Not an issue or request, but more of a PSA...

I'm a contributor for the Heroku terraform provider and was browsing providers when I noticed that this provider isn't using a go library for accessing Bitbucket APIv2. It just so happens I revamped my fork of go-bitbucket to be more feature parity with the available APIs for another project of mine. I figure this provider could benefit from the work on my fork.

Happy to contribute to this provider as well. Thanks!

David

As part of the preparation for Terraform v0.12, we would like to migrate all providers to use Go Modules. We plan to continue checking dependencies into vendor/ to remain compatible with existing tooling/CI for a period of time, however go modules will be used for management. Go Modules is the official solution for the go programming language, we understand some providers might not want this change yet, however we encourage providers to begin looking towards the switch as this is how we will be managing all Go projects in the future. Would maintainers please react with 👍 for support, or 👎 if you wish to have this provider omitted from the first wave of pull requests. If your provider is in support, we would ask that you avoid merging any pull requests that mutate the dependencies while the Go Modules PR is open (in fact a total codefreeze would be even more helpful), otherwise we will need to close that PR and re-run go mod init. Once merged, dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@master
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

GO111MODULE=on might be unnecessary depending on your environment, this example will fetch a module @ master and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/. To remove dependencies from your project, simply remove all usage from your codebase and run:

$ GO111MODULE=on go mody tidy
$ GO111MODULE=on go mod vendor

Thank you sincerely for all your time, contributions, and cooperation!

There is a new merge check available in Bitbucket Cloud, but it is not available in the provider.

Terraform Version

Terraform v0.12.20

Affected Resource(s)

bitbucket_branch_restriction

Terraform Configuration Files

resource "bitbucket_branch_restriction" "require_default_reviewer_approvals_to_merge" {
  owner      = "myteam"
  repository = "myrepo"

  pattern = "master"

  kind = "require_default_reviewer_approvals_to_merge"
}

Expected Behavior

A new branch restriction is created

Actual Behavior

Error: expected kind to be one of [require_tasks_to_be_completed require_passing_builds_to_merge force require_all_dependencies_merged push require_approvals_to_merge enforce_merge_checks restrict_merges reset_pullrequest_approvals_on_change delete], got require_default_reviewer_approvals_to_merge

  on provider.tf line 93, in resource "bitbucket_branch_restriction" "require_default_reviewer_approvals_to_merge":
  93: resource "bitbucket_branch_restriction" "require_default_reviewer_approvals_to_merge" {

Steps to Reproduce

1. terraform plan

References

https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/branch-restrictions/%7Bid%7D#put

The nightly acceptance tests were all green until 30th May 2019, when when TestAccBitbucketDefaultReviewers_basic started failing. It has been failing ever since.

From a local run:

$ make testacc
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v  -timeout 120m
?   	github.com/terraform-providers/terraform-provider-bitbucket	[no test files]
=== RUN   TestProvider
--- PASS: TestProvider (0.00s)
=== RUN   TestProvider_impl
--- PASS: TestProvider_impl (0.00s)
=== RUN   TestAccBitbucketDefaultReviewers_basic
--- FAIL: TestAccBitbucketDefaultReviewers_basic (1.15s)
    testing.go:568: Step 0 error: errors during apply:
        
        Error: API Error: 400 2.0/repositories/terraform/test-repo-default-reviewers Repository with this Slug and Owner already exists.
        
          on /tmp/tf-test148950794/main.tf line 2:
          (source code not available)
        
        
    testing.go:629: Error destroying resource! WARNING: Dangling resources
        may exist. The full state and error is shown below.
        
        Error: Check failed: Not found bitbucket_default_reviewers.test_reviewers
        
        State: <no state>
=== RUN   TestAccBitbucketHook_basic
--- PASS: TestAccBitbucketHook_basic (8.27s)
=== RUN   TestAccBitbucketRepository_basic
--- PASS: TestAccBitbucketRepository_basic (3.33s)
=== RUN   TestAccBitbucketRepository_camelcase
--- PASS: TestAccBitbucketRepository_camelcase (3.64s)
FAIL
FAIL	github.com/terraform-providers/terraform-provider-bitbucket/bitbucket	16.402s
make: *** [GNUmakefile:17: testacc] Error 1

Version

Failure occurs both on tip of master (f2f7bd2) and after Terraform 0.12 upgrade (1ecfeb2).