rdme openapi command succeeds locally, fails as github action with invalid version error
sarya opened this issue · comments
I'm trying to use Github Actions to sync an OpenAPI spec. The rdme command I'm using is in the format:
rdme openapi <path_to_file> --key=<key> --id=<api_definition_id>
Locally, the command works as expected, but when I run the same command via Actions, I get the following output:
- Validating the API definition located at <path>...
- Staging your API definition for upload...
- Updating your API docs in ReadMe...
✖ Updating your API docs in ReadMe...
Error: The version you specified (0.1.0) doesn't match any of the existing versions (0.1.0) in ReadMe.
As indicated by the output, I'm specifying the same version as the one used by my readme project, so I'm not sure why this error is occurring.
Agreed, that is a strange error 🧐 could you send across the following:
- The version of
rdmethat you're using - A copy of the GitHub Actions workflow file that is running this command (or at least the lines where the
rdmesyncing step is taking place) - A copy of your debug logs1 — see our troubleshooting docs for info on how to obtain these
Footnotes
-
These debug logs will likely contain sensitive info, so I recommend emailing them to us at support@readme.io. ↩
Was able to fix this in the end. I was setting an env variable in the workflow file for the API definition ID, but it wasn't getting mapped to its proper value when the API request was made (i.e. the URL included the text "API_DEFINITION_ID"). Ended up just including the ID directly in the rdme command. The resulting error message could probably still be improved in this case but everything appears to be working.
@sarya mind providing the info requested above? I'm having trouble reproducing that error message, would love to clean that up if possible.
Hey @kanadgupta, ran into the same error above. I first thought it was an issue with my spec so I bumped the version (from 0.1.0 to 0.2.0), but it ended up being an issue with my --id parameter. I was mistakenly using an old endpoint ID that we had deleted. Using the new ID fixed the issue. I'm betting you can recreate this by passing in a deleted or invalid ID to the openapi command.
Sorry for the delayed response @amkoehler! Believe this is happening because of #920