Continuous Integration with Apigee and Github Actions

Deploying from GitHub to Apigee X

Today I needed to setup a CI/CD pipeline for deploying our Apigee API Proxy from GitHub to our Apigee X Organization running on Google Cloud. I took a rather opinionated approach to do this, that I wanted to share with you. You might need some general GCP, Apigee and GitHub Actions knowledge for this blog post.

I don’t like dependencies, they add complexity and you need time to manage them. So when deploying to Apigee from my CI/CD pipeline I try a minimalistic approach. There are great tools out there directly from the Apigee DevRel team or great tools like apigeecli, that you might want to consider to use. My approach here was to use the handy Swiss army knife of tools: curl, which comes preinstalled on the Ubuntu instances hosted by GitHub.

The repository structure

So let’s start with the repository structure (image above). Under apiproxy/the development of the Apigee proxy is happening, for example using the great Google Cloud Code VS Code extension. In the .github/workflows/ folder you can find the GitHub Actions definition.

The focus of this blog post is on the GitHub Actions definition. So we are going to need to setup 3 things (you can find the complete GitHub Actions workflow below):

1. Line 35–42: We need to authenticate against the Google APIs in order to be able to communicate with the Apigee APIs, since GitHub Actions Tokens are OpenID Connect compliant, we can integrate the two using Workload Identity Federation. Even better, since we are not the first people that ran into this issue, we can use a great GitHub Action that already does the heavy lifting for us. The setup is a little complicated the first time but can be done quickly.
2. Line 45–49: We need to package the various XML files that make up the API Proxies into a .zip file, and upload this .zip to Apigee as a new revision. We store the revision number in an output variable of the step, so we can use it in the next step. We POST the zip to the create API endpoint to create a new revision.
3. Line 50–51: Next we want to deploy the new revision to the dev environment. Again we use curl, and POST to the deploy endpoint.

From the yaml definition you can see that 3 secrets should be set for the pipeline to work.
WORKLOAD_IDENTITY_POOL_ID takes the full name of the workload pool you created for the setup of Workload Identity Federation, e.g. projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
APIGEE_ORG the name of your Apigee organisation, normally it’s the same as your GCP project id
SERVICE_ACCOUNT the service account which the pipeline should use (you set this up when you followed the Workload Identity Federation setup guide)

The name of the proxy is hard coded into the URLs, you could extract this into a variable if you prefer. When the GitHub Actions successfully runs your output in the GitHub Actions UI should look something like this:

The build in the GitHub Actions UI

Conclusion

That’s it! Now we can easily bundle and deploy the Apigee API proxy from GitHub to GCP, thanks to Workload Identity Federation we don’t even have to export and upload secret keys to GitHub. You can find the complete example here: https://github.com/cgrotz/blog-examples/tree/main/apigee-github-actions