-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cli): docusaurus deploy should support a --target-dir option #9767
feat(cli): docusaurus deploy should support a --target-dir option #9767
Conversation
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site configuration. |
⚡️ Lighthouse report for the deploy preview of this PR
|
} | ||
|
||
// Clear out any existing contents in the target directory | ||
shellExecLog(`git rm -rf ${targetDirectory}`); |
Check warning
Code scanning / CodeQL
Unsafe shell command constructed from library input Medium
library input
shell command
Thanks, LGTM. I simplified your implementation but overall keep the intent. I confirm I can run: yarn build:website:fast
yarn workspace website deploy --skip-build
yarn workspace website deploy --skip-build --target-dir subdir Then the build folder is deployed at the gh-branch root: https://github.com/facebook/docusaurus/tree/gh-pages And then also to the subdir, without erasing what's at the root: https://github.com/facebook/docusaurus/tree/gh-pages/subdir So, it works as intended, even though we don't have great test coverage for this feature 😅 |
Pre-flight checklist
Motivation
The deploy script makes a hard assumption that the remote repository only stores Docusaurus files.
In our case we have a
CNAME
file in the root of the repo and therefore have placed all Docusaurus files in adocs
folder. Therefore, we cannot utilize this scripts since we can't specify the target directory.This PR adds a CLI option to specify the target directory and ensures that one the target directory is cleared out while the rest of the repo is left intact.
Guide for reviewer
This is an initial attempt to see if it is something that is worth finalizing and goes in the direction the maintainers of the project would like to see.
The PR is best reviewed commit by commit where each commit attempts to apply a single change. Hopefully this can help clarify if I have misunderstood how things should be implemented.
Test Plan
Would have loved to have #7714 merged for automatic validation of these changes.
Failing a snapshot test right now, I'm not a Javascript native developer and don't feel comfortable updating snapshots without understanding the implication.
The test that is currently failing should fail since I have actually added a new prop.
Test links
Deploy preview: https://deploy-preview-_____--docusaurus-2.netlify.app/
Related issues/PRs