Multiple codecommit triggers

[ghost]

This issue was originally opened by @honzous as hashicorp/terraform#17253. It was migrated here as a result of the provider split. The original body of the issue is below.

---

If I try to create 2 triggers for CodeCommit repo, I always end up with just 1 despite the state file listing both.

$ terraform -v
Terraform v0.11.2
+ provider.aws v1.7.1

Config:

resource "aws_codecommit_repository" "repository" {
	repository_name = "terraform"
}

resource "aws_codecommit_trigger" "trigger1" {
	repository_name	= "terraform"
	trigger {
		name = "trigger1"
		destination_arn = "xxxxx"
		events = ["all"]
	}
}

resource "aws_codecommit_trigger" "trigger2" {
	repository_name	= "terraform"
	trigger {
		name = "trigger2"
		destination_arn = "xxxxx"
		events = ["all"]
	}
}

Execution:

aws_codecommit_trigger.trigger1: Creation complete after 1s (ID: terraform)
aws_codecommit_trigger.trigger2: Creation complete after 1s (ID: terraform)

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Reality:

$ aws codecommit get-repository-triggers --repository-name terraform
{
    "configurationId": "f66a04fc-5123-4a50-a301-6f9df6429ea0",
    "triggers": [
        {
            "customData": "",
            "destinationArn": "xxxxx",
            "branches": [],
            "name": "trigger1",
            "events": [
                "all"
            ]
        }
    ]
}

State file showing:

"aws_codecommit_trigger.trigger1": {
    "type": "aws_codecommit_trigger",
    "depends_on": [
        "aws_codecommit_repository.repository"
    ],
    "primary": {
        "id": "terraform",
        "attributes": {
            "configuration_id": "f66a04fc-5123-4a50-a301-6f9df6429ea0",
            "id": "terraform",
            "repository_name": "terraform",
            "trigger.#": "1",
            "trigger.2907981855.branches.#": "0",
            "trigger.2907981855.custom_data": "",
            "trigger.2907981855.destination_arn": "xxxxx",
            "trigger.2907981855.events.#": "1",
            "trigger.2907981855.events.0": "all",
            "trigger.2907981855.name": "trigger1"
        },
        "meta": {},
        "tainted": false
    },
    "deposed": [],
    "provider": "provider.aws"
},
"aws_codecommit_trigger.trigger2": {
    "type": "aws_codecommit_trigger",
    "depends_on": [
        "aws_codecommit_repository.repository"
    ],
    "primary": {
        "id": "terraform",
        "attributes": {
            "configuration_id": "20400a71-aa9a-418c-a454-a8b228529c0a",
            "id": "terraform",
            "repository_name": "terraform",
            "trigger.#": "1",
            "trigger.2671465289.branches.#": "0",
            "trigger.2671465289.custom_data": "",
            "trigger.2671465289.destination_arn": "xxxxx",
            "trigger.2671465289.events.#": "1",
            "trigger.2671465289.events.0": "all",
            "trigger.2671465289.name": "trigger2"
        },
        "meta": {},
        "tainted": false
    },
    "deposed": [],
    "provider": "provider.aws"
},

[ilyash-b]

Looking at the code, I've seen that only triggers given in single aws_codecommit_trigger are taken into account. I have confirmed this behaviour by creating TF file (see below). Resource "aws_codecommit_trigger" "multi-trigger-a" works as expected; resources "aws_codecommit_trigger" "single-trigger-a" and "aws_codecommit_trigger" "single-trigger-b" are mutually exclusive.

Since the update logic is wrong, you can't manage (seemingly unrelated) triggers of one repository from different TF workspaces for example. The triggers are just overridden and you end up just with triggers defined in the single last aws_codecommit_trigger that was applied.

resource "aws_sns_topic" "topic" {
	name = "t1"
}

resource "aws_codecommit_repository" "single-trigger-repo" {
	repository_name = "single-trigger-repo"
}

resource "aws_codecommit_repository" "multi-trigger-repo" {
	repository_name = "multi-trigger-repo"
}

resource "aws_codecommit_trigger" "single-trigger-a" {
	repository_name = "single-trigger-repo"
	trigger {
		name = "st-a"
		destination_arn = "${aws_sns_topic.topic.arn}"
		events = ["all"]
	}
}

resource "aws_codecommit_trigger" "single-trigger-b" {
	repository_name = "single-trigger-repo"
	trigger {
		name = "st-b"
		destination_arn = "${aws_sns_topic.topic.arn}"
		events = ["all"]
	}
}

resource "aws_codecommit_trigger" "multi-trigger-a" {
	repository_name = "multi-trigger-repo"
	trigger {
		name = "multi-a"
		destination_arn = "${aws_sns_topic.topic.arn}"
		events = ["all"]
	}
	trigger {
		name = "multi-b"
		destination_arn = "${aws_sns_topic.topic.arn}"
		events = ["all"]
	}
}

[ilyash-b]

It seems that resourceAwsCodeCommitTriggerDelete deletes all triggers, so if you remove for example resource "aws_codecommit_trigger" "single-trigger-b" - you end up with no triggers at all.

[trilitheus]

Seeing the same issue - adding two triggers to codecommit as I build two different docker images from the same repo:

resource "aws_codecommit_repository" "MY_REPO" {
  repository_name = "MY_REPO"
  description = "docker source"
}

resource "aws_codecommit_trigger" "build_image_1" {
  depends_on = ["aws_codecommit_repository.MY_REPO"]
  repository_name = "MY_REPO"

  trigger {
    name = "build_image_1"
    events = ["all"]
    destination_arn = "${aws_lambda_function.build_docker_images.arn}"
    custom_data = "${module.image_1.buildproject_name}"
  }
}

resource "aws_codecommit_trigger" "build_image_2" {
  depends_on = ["aws_codecommit_repository.MY_REPO"]
  repository_name = "MY_REPO"

  trigger {
    name = "build_image_2"
    events = ["all"]
    destination_arn = "${aws_lambda_function.build_docker_images.arn}"
    custom_data = "${module.image_2.buildproject_name}"
  }
}

As per others I'm seeing onely one trigger even though terraform state contains both.

[roeezab]

Same issue here (with aws provider v2.17.0).
Until fixing this bug, I believe this should be documented as a warning, because it deletes manually-created triggers as well.

[bflad]

We would like to address the duplicate Terraform resource problem, more generically for all Terraform resources that could be potentially duplicated by certain criteria (such as per-region and per-name). The enhancement that would be available to all Terraform resources, which we could then implement the Terraform AWS Provider, can be tracked upstream in the Terraform Plugin SDK: hashicorp/terraform-plugin-sdk#224.

This certainly doesn't preclude documenting the current situation though as mentioned above. If anyone would like to contribute that, the source for the resource webpage is here: https://github.com/terraform-providers/terraform-provider-aws/blob/master/website/docs/r/codecommit_trigger.html.markdown

And adding a yellow box can be done with the following:

~> **NOTE:** Message here

[roeezab]

This certainly doesn't preclude documenting the current situation though as mentioned above. If anyone would like to contribute that, the source for the resource webpage is here: https://github.com/terraform-providers/terraform-provider-aws/blob/master/website/docs/r/codecommit_trigger.html.markdown

Opened PR #10773.

[lgallard]

Any advance on this issue? Same behaviour in provider v2.62.0 :(

[lgallard]

By the way, shouldn't be the trigger block a dynamic block? This way you don't need to declare multiple aws_codecommit_trigger resources for the same repo.

In fact, trigger blocks should be able to be declared multiple times inside theaws_codecommit_repository resource like this:

resource "aws_codecommit_repository" "repo" {
  repository_name = "repo"
  
  trigger {
    name            = "all"
    events          = ["all"]
    destination_arn = aws_sns_topic.topic_all.arn
  }

  trigger     {
      name            = "updateReference"
      events          = ["updateReference"]
      destination_arn = "arn:aws:lambda:us-east-1:123456789101:function:lambda_updateReference"
    },

}

[bflad]

Hi folks 👋 Thank you for submitting this and this is an excellent use case of somewhere that Terraform and the Terraform AWS Provider could be much more helpful since in many cases they have enough information to return an error upfront during planning instead of unexpected behavior during apply.

I believe this falls under the provider-wide enhancement proposal of #14394, so by adding this link here it will add a reference to that issue so we can include it as a use case when thinking about the implementation details. Since this is likely something we will want more broadly across many resources, I'm going to close this particular issue to consolidate discussions, efforts, and prioritization on the topic while the reference would serve as the cue to make this specific resource one of the initial implementations. I would suggest those 👍 upvoting and subscribing here to do so on #14394 so we can appropriately gauge interest. Please feel free to provide feedback there.

Thanks again!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!