[Bug]: "Compatibility Wrapper" object docs written to wrong part of tree
Current Behavior:
PlanSecurity* transaction markdown is being written to docs/schema_markdown/PlanSecurity*.md instead of docs/schema_markdown/schema/objects/transactions/*/PlanSecurity*.md. This may only happen on releases for some reason.
Expected Behavior:
Markdown should be written to the same paths as other txns.
Steps to Reproduce:
Feel free to replace 1.1.0 with some other fake release version.
node --loader ts-node/esm --no-warnings --experimental-json-modules ./utils/schema-utils/EnforceCopyrightNotices.ts check-notices -fvart --tag v1.1.0 && git add schema utils
# updates ids and refs
npm run generate-release-docs 1.1.0 && git add schema utils
# manually update enums
# search and replace all JSON files replacing manifest version with "1.1.0"
# generate docs
rm -rf docs/schema_markdown/**/*.md # delete everything first, fresh start
npm run generate-docs && git add docs/schema_markdown
Environment:
MacOS 12.16, Node 16.16, npm 9.6.4
Anything else we need to know?
Follow-up on #422
@pjohnmeyer, can you try this again? I'm not seeing this behavior.
@JSv4 still happens, steps to reproduce have changed slightly due to time. I used v9.9.9 below so you can just copy and run each step if you're so inclined.
node --loader ts-node/esm --no-warnings --experimental-json-modules ./utils/schema-utils/EnforceCopyrightNotices.ts check-notices -fvart --tag v9.9.9 && git add schema utils
# updates ids and refs
npm run docs:generate-release 9.9.9 && git add schema utils
Then manually update enums, search and replace all JSON files replacing manifest version with "9.9.9".
# generate docs
rm -rf docs/schema_markdown/schema # delete everything first, fresh start
npm run generate-docs && git add docs/schema_markdown
Here is the output of git status after I run the above, note the added and deleted files
Think I got it @pjohnmeyer. If you have time tomorrow morning, can you check that the md outputs are the same? I will try to check too before our release coordination call.
This was still an issue when we went to do the v1.2.0 release. Need to investigate further.