Automating Code Reviews with Amazon Q and GitHub Actions

Hello!! This is my first blog post on the AWS forums - My Organization has recently adopted Amazon Q Developer and with my DevOps brain having lived and breathed CI/CD for the past 5 years - Just wanted to share how I managed to get Amazon Q working within a GitHub actions pipeline.

This post is primarily a proof of concept on how you can integrate the Amazon Q Developer CLI into your CI/CD pipeline. But before diving into the technical details, it’s worth asking: why would you want to do this in the first place?

The answer is simple—efficiency. AI is all about optimizing workflows, and if Amazon Q can handle automated and reliable code reviews, that means less time spent on manual review and more time for developers to focus on writing great code.

For this example - I will be using GitHub Actions, but the same approach can be done with any CI/CD pipeline, or even as part of a docker build process.

Note:
This setup has only been used in a Proof of Concept environment, If you are wanting to use this in a production setting, please ensure you have approval and from your DevOps & Security team and have the appropriate guardrails in place before attempting the below.

Below is a sample GitHub Action for installing and running Amazon Q! This pipeline will specifically run on pull requests to the "main" branch. But you can use GitHub Actions to integrate this into any existing workflows you have.

So, lets see how it runs??

Turns out, by default. Not well... as we haven't authenticated the CI/CD context with Amazon Q developer.

Right, so with most "modern" CI/CD pipelines, we have disposable agents that either run on VMs or Docker Containers, meaning, these are usually stateless. So by default, our Amazon Q Developer will be always logged out. If you are hosting your own CI/CD infrastructure, you may have stateful agents that you could manually log in to and reauthenticate with when needed. But I will also take the liberty of showing you how you can persist Amazon Q Developer's session between builds.

 You can initiate the login process by running the q login command. This opens an interactive terminal session below, which isn't the most ideal from a CI/CD perspective, as we have to provide manual actions in the terminal to authenticate.

For this walkthrough, run the q login command on your local machine, and NOT the CI/CD pipeline.

Follow the prompts on your interactive terminal to authenticate with Q.

My recommendation for regular use is to use a Service account with a Pro license - however if you are trialing this, a free account will do. Just be aware of the service quotas of the Free Amazon Q Developer offering, as this may not be suitable for day to day usage within your organization.

Once logged into Amazon Q cli - check you are logged in with the command q chat "Hello Amazon Q!"
You should see something similar to the below.

For Linux (Ubuntu), the local credentials for Amazon Q developer are stored in the following location.

To Authenticate the CI/CD context, we will need to persist these to some shared location.
I have used S3 for this example as that was the quickest. But this does contain sensitive data, so I would consider implementing additional security measures through S3 VPC endpoints (if hosting your own runners), or by using something like secrets manager or SSM parameter store.

I uploaded these to S3 by running the below.

Now we have the authentication persisted, we can authenticate the CI/CD pipeline with Amazon Q Developer.

This assumes we have pre-existing authentication with AWS that can access our S3 bucket. - If you need to set this up, see the "Configure AWS Credentials" documentation to set this up.

Your job should now be returning output from the Amazon Q Developer CLI

To invoke slash commands via the Amazon Q cli we need to run the `q chat` command in a special format

e.g.

However running this will often lead to an interaction prompt in the Amazon Q context.

This isn't compatible with the CI/CD pipeline as its non-interactive so we need to use the --accept-all flag to 'Auto Approve' any commands to be run.

So, the command we run in GitHub Actions is.

Now our GitHub actions pipeline looks like this!

Now your pipeline should be showing something like this - For the below I have asked it to review a sample Micronaut project based on the Coffee Machine TDD Project

It looks like its picked all very valid issues that shouldn't be exposed to a production environment. Usually it would take weeks of product reviews and meetings to review and identify all these. And Amazon Q Developer has done this in about 3 minutes!

This full working example below makes a list of the files changes in the Pull Request, tells Amazon Q Developer to review them, and asks it to put a comment on the Pull Request.

 If you got this far, thanks for reading ! - Let me know your thoughts and if you've done something similar with Amazon Q!