Add optional workspace-dir input to set where the generation script runs#1
Draft
sionleroux wants to merge 5 commits intomsayson:mainfrom
Draft
Add optional workspace-dir input to set where the generation script runs#1sionleroux wants to merge 5 commits intomsayson:mainfrom
sionleroux wants to merge 5 commits intomsayson:mainfrom
Conversation
Running the script from the repo root works fine if your OpenAPI spec is all in one file, but if it is in separate files it fails because the main schema references them relative to itself but the script is looking for them relative to the directory it's running in, which is not necessarily the same. For example, if the schemas are in schemas.json and you include it in the main file with a file reference and their both in a docs/ directory, you'll get an error like this: Invalid JSON pointer: ./schemas.json#/components/schemas/something You can solve this by moving all the OpenAPI files to the root of the repository where the script is run from but that clutters the repo root. Alternatively you can run the script from the directory the files are in so that the relative paths are correct. For this second option users need to be able to specify a directory relative to the repo root as the base path for the OpenAPI schemas if their spec is structured this way. The new, optional, input `workspace-dir` will be appended to the `github.workspace` path when setting the `WORKSPACE_DIR` environment variable that the generation script is already using. This way the script will go that directory instead of the repo root and it'll be able to find the referenced files.
sionleroux
force-pushed
the
workspace-dir
branch
from
13c6e2b to
8024bc8
Compare
The join expression expects an array as input but it's not clear how you can make an array yourself during the script, it seems to only support ones that are made for you by the runtime. Format supports arbitrary input though, so it should work. A trailing or double slash shouldn't matter if the underlying FS is Linux-like.
If WORKSPACE_DIR isn't the repo root then at the end the next actions can't find the generated files to publish to GitHub pages.
Author
|
I can't figure out why changes I'm making in my fork of this script don't seem to be applied at all. I've added some print-style debug lines but none of it prints even though both branches are covered, it still just reaches the "Failed" message right after falling back to local files. I'll revisit this later because I think it would be nice if this worked, but for now I've worked around my problem by setting cd docs && npx @redocly/cli bundle Openapi.yml > ../Openapi.ymlTo generate a single Openapi.yml file that this action is happy to consume. |
Owner
|
Thanks for the input! I'll be happy to take a look if you're able to get a working version of this. Will want a test GitHub workflow yaml file added that validates the multi-file use case before merging changes into the main branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Running the script from the repo root works fine if your OpenAPI spec is all in one file, but if it is in separate files it fails because the main schema references them relative to itself but the script is looking for them relative to the directory it's running in, which is not necessarily the same. For example, if the schemas are in schemas.json and you include it in the main file with a file reference and their both in a docs/ directory, you'll get an error like this:
You can solve this by moving all the OpenAPI files to the root of the repository where the script is run from but that clutters the repo root. Alternatively you can run the script from the directory the files are in so that the relative paths are correct. For this second option users need to be able to specify a directory relative to the repo root as the base path for the OpenAPI schemas if their spec is structured this way.
The new, optional, input
workspace-dirwill be appended to thegithub.workspacepath when setting theWORKSPACE_DIRenvironment variable that the generation script is already using. This way the script will go that directory instead of the repo root and it'll be able to find the referenced files.I wasn't able to run the tests on my laptop unfortunately so I can't guarantee that this change causes no regressions. I think it should be fine though. Thanks for considering my pull request 🙂