Add GitHub Actions workflow to deploy JSDoc to GitHub

[minggangw]

Automate the JSDoc deployment that was previously a manual npm run docs:gh-pages + push-to-gh-pages process. The workflow leverages the existing github-pages deployment environment.

Trigger

• Tag push matching docs-* (e.g. docs-1.9.0) — builds and deploys
• Manual workflow_dispatch with a dry_run toggle (defaults to true) — build-only by default, deploy when dry_run is unchecked

Build job

• Full checkout (fetch-depth: 0) with tags, plus explicit origin/gh-pages fetch — required by regenerate-published-docs.js to discover and preserve previously published versions
• Runs npm run docs:gh-pages to stage the full docs tree under build/gh-pages-docs/
• Uploads the output via upload-pages-artifact

Deploy job

• Skipped when dry_run is true
• Deploys to GitHub Pages via deploy-pages@v5

Changes

File	What changed
.github/workflows/deploy-docs.yml	New workflow

Fix: #1489

[Copilot]

Pull request overview

Adds an automated GitHub Actions pipeline to build and deploy versioned JSDoc output to GitHub Pages, replacing the prior manual npm run docs:gh-pages + push-to-gh-pages process.

Changes:

• Introduces a new deploy-docs.yml workflow to build docs on docs-* tag pushes (and via manual dispatch) and deploy to GitHub Pages.
• Updates the JSDoc workflow README with instructions for the new CI-based deployment and basic testing guidance.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tools/jsdoc/README.md	Documents the new CI-based docs build/deploy workflow and how to trigger/test it.
.github/workflows/deploy-docs.yml	New GitHub Actions workflow to build JSDoc, upload as Pages artifact, and deploy to GitHub Pages.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The workflow is guarded by if: github.repository == 'RobotWebTools/rclnodejs' in the build job, so manual dispatches (and tag pushes) in forks will result in a skipped build. Consider documenting this constraint here (e.g., “only runs in the upstream RobotWebTools/rclnodejs repo”) to avoid confusion when contributors try to test it from their fork’s Actions tab.

Suggested change

	These workflow runs only execute in the upstream `RobotWebTools/rclnodejs`
	repository. If you trigger the workflow from a fork, the build job is skipped,
	so manual dispatches and `docs-*` tag pushes there will not run the docs build.

[Copilot]

The “Push a docs-test tag to trigger a full build + deploy” guidance will update the live GitHub Pages site (since docs-* tags deploy by default). Consider adding an explicit warning that this is a production deployment and should only be used when it’s acceptable to update published docs (or recommend using workflow_dispatch with dry_run first).

Suggested change

	- Run the workflow manually with `dry_run` enabled to verify the build
	succeeds without deploying.
	- Push a `docs-test` tag to trigger a full build + deploy, then clean up:
	- Run the workflow manually with `dry_run` enabled first to verify the build
	succeeds without deploying.
	- Only push a `docs-test` tag when it is acceptable to update the published
	GitHub Pages site: this trigger performs a real production build + deploy
	for `docs-*` tags. Afterward, clean up the tag with

[coveralls]

coverage: 85.864%. remained the same — minggangw:fix-1489 into RobotWebTools:develop