TL;DR

By setting the codepipeline-artifact-revision-summary metadata key when uploading a build artifact to S3, you can get nicer source metadata information from AWS CodePipeline.

Better CodePipeline S3 Source Metadata

When using AWS CodePipeline with an S3 source, by default the CodePipeline UI will display the S3 version id of the artifact:

If your artifact is getting placed in S3 as part of a CI workflow, then this S3 version id isn’t very helpful.

Instead, having info identifying the source commit would tell us much more about what is being deployed:

Above, we see the short git commit sha, the date of the commit, the author, and the commit message.

In this post, I will show an example of how this can be done with Bitbucket using their Pipelines feature.

codepipeline-artifact-revision-summary

The way to get better revision summaries is to set a special metadata key when putting the artifact on S3.

The metadata key is called codepipeline-artifact-revision-summary and it is documented in the revisionSummary field of the ArtifactRevision API reference for CodePipeline:

revisionSummary

Summary information about the most recent revision of the artifact. For GitHub and AWS CodeCommit repositories, the commit message. For Amazon S3 buckets or actions, the user-provided content of a codepipeline-artifact-revision-summary key specified in the object metadata.

Type: String

Length Constraints: Minimum length of 1. Maximum length of 2048.

Required: No

Setting it using the aws cli looks like this:

$ aws s3 cp app.zip s3://my-bucket/ --metadata '{"codepipeline-artifact-revision-summary":"my fixes"}'

Now that we know how to control what is shown as the source metadata, let’s look at the details of setting this from a Bitbucket pipeline.

Setting Source Metadata via Bitbucket Pipelines

Bitbucket has a nice pipeline feature which enables CI/CD via a configuration file in a repo. Here is an example bitbucket-pipelines.yml that will trigger a build after every commit.

The build installs some dependencies, exports the AWS variables needed, zips up the source, generates the summary, and uploads to s3 while setting the source metadata as shown above - take a quick read and then we’ll discuss:

The important part of this for us is the generatesummary block on lines 13-25. Here, we first use git log to get a good short description of the commit. Then, we replace newlines and tabs with spaces, escape double quotes, and then limit the overall length of the summary to 2010 characters. That gives us our SUMMARY variable, which we use on line 28 to set the codepipeline-artifact-revision-summary as we upload to S3. And we end up with something like this!

I hope this helps to bring better descriptions to your CodePipelines with S3 sources.

Happy Coding!

Dylan