<!--Hello curious raw Markdown reader! 👋 This Markdown page is syncing to ReadMe via the `rdme` GitHub Action 🦉 Read more [on our main documentation page](🔗) -->

❗️Deprecated in favor of [our new GitHub Action, `rdme`](🔗) 🔄

This GitHub Action has been deprecated in favor of our newer (and more fully-featured) GitHub Action, [`rdme`](🔗), which has support for syncing OpenAPI files, syncing Markdown files, and much more.

If you previously used ReadMe's [legacy GitHub Action](🔗), you are welcome to continue doing so if it's working for you. It will continue to run in existing workflows for the foreseeable future, but all development and support for this tool has been closed. To ensure your workflows continue to operate and are taking advantage of our latest features, we strongly recommend switching to [`rdme`](🔗). Check out the migration guide below!

## Migrating to `rdme`

If you previously had a GitHub Workflow file set up that used this action to sync your OpenAPI file to ReadMe, you had a step in your workflow that looked something like this:

where the `readme-oas-key` was a concatenation of `<<user>>` (the API key for <<name>>) and `API_DEFINITION_ID` (your API definition ID), separated by a colon.

For migrating to [the `rdme`-based GitHub Action](🔗), modify the step to look like this:

There are a few things to note:

1. This workflow will infer the `api-version` based on the `API_DEFINITION_ID` parameter that you pass in, so the API version parameter is no longer needed here.

2. `@v8` is the latest version of `rdme`. To ensure you're getting the latest features and security updates, we strongly recommend setting up [Dependabot](🔗) to keep this package up-to-date.

3. If you used secrets to encrypt the `readme-oas-key` value, you'll have to split this value out into two separate secrets—one for the API key and one for the API definition ID. You can see an example of this [here](🔗).

<details>

<summary>View the legacy docs below!</summary>

## Legacy Docs

With [GitHub Actions](🔗), you can automatically sync your OpenAPI document whenever changes occur in your GitHub repo!

❗️Deprecated workflow instructions below

As a reminder, the `readmeio/github-readme-sync` GitHub Action that's described below is now deprecated. The instructions are preserved for posterity. We strongly recommend all new and existing workflows use our newest GitHub Action: [`rdme`](🔗)!

Create a new file in your GitHub repository called `.github/workflows/readme-github-sync.yml` and populate it with the template below. You only fill in one parameter from the ReadMe Dashboard and you'll be good to go!

Any subsequent commits to the `main` or `master` branch (whichever is your default branch—you can also specify any GitHub event of your choice—see [GitHub's docs](🔗) for more info) will automatically trigger the sync process and upload your specified OpenAPI file to ReadMe.

🚧

Public Repo? Secretly store your ReadMe API Key!

GitHub Actions have a way to securely store sensitive information (such as your ReadMe API Key and API Specification ID), so it isn't publicly visible. You can read more [in their documentation](🔗).

### Migrating Existing APIs to GitHub Sync

You can also migrate APIs that are already synced into ReadMe via another mechanism. The value for `readme-oas-key` is your [ReadMe Project API Key](🔗) and the API Specification ID (pictured below) separated by a colon (i.e. `apiKey:apiSpecId`).

Use `readme-oas-key` in your `.github/workflows/readme-github-sync.yml` file and any subsequent pushes to the `master` branch (or whichever branch(es) you specify in your workflow file) in that GitHub repository will sync that OpenAPI file to ReadMe!

📘

Keeping Your GitHub Action Up-to-Date

To ensure that you're on the latest version of our GitHub Action (along with all of your project dependencies), we highly recommend [setting up Dependabot](🔗), which automatically updates your project dependencies (including this one!). As a fallback, we recommend keeping your version of the `github-readme-sync` package set to `v2` as denoted above, which ensures that your workflow will execute the latest available version within the version 2 range.

### Troubleshooting

If you're seeing failures with the GitHub Action and need to troubleshoot the issue, we provide comprehensive step-by-step debug logs. We may ask for these logs (as well as a copy of your API specification file) when you contact our support team. You can enable [Step Debug Logs](🔗) in your GitHub Actions workflow by [setting the repository secret](🔗) `ACTIONS_STEP_DEBUG` to `true`. For more information on accessing, downloading, and deleting logs, check out [GitHub's documentation](🔗).

🚧

Debug Logs May Contain Sensitive Information

Enabling [Step Debug Logs](🔗) will produce comprehensive logging for **all** of your GitHub Actions workflows. While we sanitize all logging output to prevent API keys from being visible, the logs may contain other sensitive information (from ReadMe and any other services that you use). Anybody with read access to the repository will be able to see these logs.

We **strongly recommend** that you only enable this setting in private repositories. If working in a public repository, we suggest creating a separate private repository with your GitHub workflow and OpenAPI/Swagger files before enabling this debugger.

If you do enable Step Debug Logs in your repository and your logs produce sensitive information, here are [GitHub's docs on deleting logs](🔗).

### Example

Want to see the GitHub Action in action? Check out this example repository: [kanadgupta/metrotransit-nextrip-oas](🔗)

To see an example where multiple OpenAPI/Swagger files are synced in the same repository, check out [jesseyowell/oas-test-files](🔗).