Bump.sh

Migrate from Redocly

Redocly is a hosted OpenAPI documentation SaaS which works in a similar way to Bump.sh: you work on OpenAPI wherever you want, then publish it up to Redocly via various Git hosting providers or Continuous Integration. The fact that it works so similarly means you can switch from Redocly easily, and start getting all the extra benefits of breaking change detection and an API changelog with minimal effort.

Step 1: Find your OpenAPI #

Most users will have set Redocly up to pull from GitHub, GitLab, or Bitbucket, making this stage very simple. You already have your OpenAPI in your control. Going to “Settings” > “Source” will remind you exactly which repository, which branch, and which file exactly.

If you are using some more complex CI/CD setup and have no idea where your OpenAPI originates, and the people who knew have left the company without a trace, you can export OpenAPI from Redocly.

Get the downloaded OpenAPI into your source code repository somewhere sensible, and give it a tidy name in the process.

mv ~/Downloads/swagger.yaml ~/src/train-travel-api/openapi.yaml

Now you can add this OpenAPI to your source control, which assuming Git is a case of:

cd ~/src/train-travel-api

git add openapi.yaml

git commit -m "docs: imported openapi"

Step 2: Publish OpenAPI as Documentation #

Instead of installing a GitHub Application, Bump.sh uses a GitHub Action for deployments. Alternatively you can get creative with the command-line, using a Continuous Integration setup, or even deploying via the Bump.sh API.

# .github/workflows/bump.yml

name: Check & deploy API documentation

on:
  push:
    branches:
      - main

  pull_request:
    branches:
      - main

permissions:
  contents: read
  pull-requests: write

jobs:
  deploy-doc:
    if: ${{ github.event_name == 'push' }}
    name: Deploy API documentation on Bump.sh
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Deploy API documentation
        uses: bump-sh/github-action@v1
        with:
          doc: <BUMP_DOC_ID>
          token: ${{secrets.BUMP_TOKEN}}
          file: doc/api-documentation.yml

  api-diff:
    if: ${{ github.event_name == 'pull_request' }}
    name: Check API diff on Bump.sh
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Comment pull request with API diff
        uses: bump-sh/github-action@v1
        with:
          doc: <BUMP_DOC_ID>
          token: ${{secrets.BUMP_TOKEN}}
          file: doc/api-documentation.yml
          command: diff
        env:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

Grab your Doc ID and Access Token from the Automatic Deployment settings, pop the Doc ID into the GitHub Action and put the API specific BUMP_TOKEN into the GitHub repository Secrets.

This workflow will have Bump.sh make previews on Git branches, then deploy the main version of the documentation when a branch is merged. By doing this the pull requests also get change detection, allowing for warnings about breaking changes, and making a simple list of changes to help with design reviews.

A side benefit of working this way is that you can defer all configuration about how reviews work, what checks should be involved, who is in charge of approving changes, etc. to the pull request settings of your source control.

Once a guide is published you can view the hosted documentation on Bump.sh, and it will look a little something like this: Train Travel API Documentation.

Step 3: Use Hubs to Replace Developer Portals #

If you were using the Developer Portals feature with Redocly to group together multiple APIs, you can use Hubs to recreate this functionality and provide a landing page for each group of APIs.

Vendor Extension Compatibility #

Both Redocly and Bump.sh support vendor extensions, which are non-standard additions to the OpenAPI, starting with an x- like x-logo. Some extensions are based on common conventions, but some are vendor specific, and some are there to support functionality that was missing in older versions of OpenAPI that are no longer needed.

Bump.sh Supports #

  • x-topics - Add more context paragraphs in your generated documentation. Learn more.

  • x-codeSamples - Add your own code samples in one or more programming languages to your documentation. Learn more.

  • x-beta - Allows you to identify some components of your documentation as beta. Learn more.

To help you with your migration, here is a full list of the extensions Redocly support, with suggestions of alternative approaches where they exist.

Location Extension Keyword Bump.sh Alternative
Root x-servers Use the servers keyword added in OAS3.0
Root x-tagGroups  
Tag Group x-ignoredHeaderParameters  
Info x-logo Upload a logo using customization settings.
Tag x-traitTag  
Tag x-displayName Use human-readable tag names.
Operation x-codeSamples  
Parameter x-examples Use the examples keyword added in OAS3.0.
Response x-summary  
Schema x-nullable Use the nullable keyword added in OAS3.0 or type: null added in OAS3.1
Schema x-extendedDiscriminator Discriminator is confusing, poorly supported, and best avoided. Use oneOf instead.
Schema x-additionalPropertiesName Both additionalProperties and newer unresolvedProperties now accept a schema that can contain this extra information and more.
Schema x-explicitMappingOnly Discriminator is confusing, poorly supported, and best avoided. Use oneOf instead.