Codeship API v2 Is Now in General Availability

Codeship News

Reading Time: 3 minutes

After a few months in public beta and handling close to a million requests a month, including requests from some of our biggest customers, we’re excited to announce that our new API is now in general availability.

We’ve been very satisfied with the performance and stability of the API, and we’d like to invite you to start using it to automate your own workflows. If you’re wondering what you could do with the API, we’ve included a few examples below that have come up during the beta.

Triggering Builds

Not all builds needs a code change, and the new API allows you to trigger those builds without doing empty commits.

We’ve seen this particular workflow implemented by Sage. They wanted to automate the process of updating their web app EC2 AMIs, which is built using Codeship Pro and the official Packer Docker image.

The project pulls the latest packages, security patches, etc., ensuring that everything is always up to date. Obviously, the Ansible scripts themselves wouldn’t need to constantly be updated, so what Sage needed was a reliable way of triggering the scripts, either manually or on a schedule.

The final solution is a Lambda script (which you can view here) that triggers a new build on a schedule based on a particular commit. The AMI is built on Codeship and pushed to AWS, where a separate process ensures that the latest image is always used to boot the EC2s.

To manage the secrets needed for the API, Sage defined a KMS encrypted variable, which is used within the Lambda script to retrieve the correct credentials.

Custom Dashboards

Tool-specific dashboards are fine, but sometimes you want to combine your CI metrics with your issue tracker and possibly your production monitoring. The new API enables you to pull all history for all builds, allowing you to build out your own dashboard with data from multiple systems.

If you’re looking for inspiration on how to get started, Karl Hughes takes you through an example in his blog post, Creating a Custom Build Status Page Using Codeship.

Auto-creating Projects

This is especially useful if you often create new projects, even if they’re not that similar. With the API, you can create just a skeleton project or define standard notification rules, team access, etc.

Note that only Pro projects are fully supported with this release (full support for Basic projects will be added Jan 2018).

A great example of this is from another of our large customers, working on automating their project creation flow. Whenever a new repo is added to their organization, a script will automatically provision a project on Codeship, which is linked to the newly created repo. This allows them to template standard projects and make the initial setup much faster.

!Sign up for a free Codeship Account

What’s the Future?

The main idea with our API has always been to provide more flexibility, to allow you to integrate Codeship into your own workflow. The scenarios above hint at some of the things that can be built, but really anything that involves historic build data, triggering builds, or creating projects can likely be automated using Codeship’s new API.

Early 2018, we’ll add full support for working with Codeship Basic projects, and going forward, you can expect to see new features added to the overall product also become available through the API.

We’re excited to see how you will use the API, and we’ll be happy to help you get started if needed. Also, if you have any ideas as to how we can improve the API, feel free to reach out to me as well; we appreciate all the feedback we get, and it helps us provide a better solution for you.

Codeship API v1

Note that with the public release of v2, the v1 API will be deprecated by July 1, 2018. Hopefully this is enough notice to give you time to migrate to v2, but do reach out if you need any help getting going.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.



We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Chris Lee

    Congratulations you guys!

  • A little confused about the ambiguity between ‘ref’ and ‘branch’ (and also ‘commit_id’ and ‘commit_sha’) in your API documentation. For instance, in https://apidocs.codeship.com/v2/builds/create-build the example request body uses ‘branch’ and ‘commit_id’, but the response comes back saying ‘ref’ and ‘commit_sha’ are missing (which matches the documentation). However the mock response comes back using ‘branch’ and ‘commit_id’ again. Is this confusion just caused by the mocks?

    • Dennis Newel

      Sorry @nikrolls:disqus , looks like the examples have drifted out of sync with the spec. I’ll try and get them updated to avoid the confusion. You’re correct in your assumption though that it’s just the examples and the mocks that refer to commit_id and branch; we corrected the terminology during the beta i think, but must have missed the examples.

    • Dennis Newel

      we’ve updated some of the examples. The one you found was actually worse than i though; that endpoint doesn’t give you any response payload as it’s normal response is a 202.

      Let me know if you come across other things; we keep checking this stuff but might still miss a thing or two

      btw: what are you planning to use the API for? we’re happy to help you get started/unstuck if you need some assistance :)