How to trigger CodePipeline for GitHub pull requests being merged?

Question

How can I configure CodePipeline to be triggered for Pull Requests being opened, edited or merged?

Here is a Terraform configuration:

resource "aws_codepipeline_webhook" "gh_to_codepipeline_integration" {
  name            = "gh_to_codepipeline_integration"
  authentication  = "GITHUB_HMAC"
  target_action   = "Source"
  target_pipeline = aws_codepipeline.mycodepipeline.name

  authentication_configuration {
    secret_token = var.github_webhook_secret
  }

  // accept pull requests
  // Is there a way to filter on the PR being closed and merged?  This isn't it...
  filter {
    json_path    = "$.action"
    match_equals = "closed"
  }

}

CodePipeline is set to accept webhook events that have all of the conditions specified in the filters, which corresponds to Pull Request Events.

Note that the GitHub documentation states for the action field of a PullRequestEvent (my emphasis in bold):

The action that was performed. Can be one of assigned, unassigned, review_requested, review_request_removed, labeled, unlabeled, opened, edited, closed, ready_for_review, locked, unlocked, or reopened. If the action is closed and the merged key is false, the pull request was closed with unmerged commits. If the action is closed and the merged key is true, the pull request was merged. While webhooks are also triggered when a pull request is synchronized, Events API timelines don't include pull request events with the synchronize action.

It seems like I need to filter for both $.action==closed && $.pull_request_merged=true, but it doesn't look like I can do both. If I just filter on $.action==closed then my pipeline will rebuild if PRs are closed without merging. Is this an oversight on my part, or are CodePipelines not as flexible in their triggers as CodeBuild projects?

Answer 1

For pull requests being opened/updated, because CodePipeline's Git integrations require a branch name, this is not natively supported as the branch name is variable, unless you open PRs on long running branches like dev, qa etc (e.g. if you are using a Gitflow-based workflow).

The way that we support PRs based from dynamic branches is use CodeBuild for the build/unit test stage of our workflow, and then package up the repository and build artefacts to S3. From there we trigger Deployment pipelines for integration and acceptance environments using S3 artefact as the source. Using CodePipeline for deployments is powerful as it automatically ensures only one stage can execute at a time, meaning only one change for a given application is going through a given environment at any one time.

This approach is however quite complex and requires quite a bit of Lambda magic mixed with SQS FIFO queues to deal with concurrent PRs (this is to overcome the superseding behaviour of CodePipeline), but it's quite a powerful pattern. We also use GitHub reviews to do things like trigger acceptance stage, and auto-approve manual approval steps in CodePipeline.

Once you are ready to merge the PR, we just use normal CodePipeline triggered off master to deploy to production - one thing you also need to do is ensure you use the artefact that was built and tested on the PR.