Skip to content

Update antora#131

Open
gpx1000 wants to merge 12 commits intoKhronosGroup:mainfrom
gpx1000:update-antora
Open

Update antora#131
gpx1000 wants to merge 12 commits intoKhronosGroup:mainfrom
gpx1000:update-antora

Conversation

@gpx1000
Copy link
Collaborator

@gpx1000 gpx1000 commented Aug 30, 2025

No description provided.

@oddhack
Copy link
Collaborator

oddhack commented Aug 31, 2025

This is odd - it is open but looks like it has already been merged to main. Did you push this directly to main branch as well as open the MR?

@gpx1000
Copy link
Collaborator Author

gpx1000 commented Aug 31, 2025 via email

@oddhack
Copy link
Collaborator

oddhack commented Aug 31, 2025

Yeah I made a mistake so reverted it.. it still needs the change merged

Are you saying you want this branch merged as it is, or that you want to do something to this branch before we merge it? Confused.

@gpx1000
Copy link
Collaborator Author

gpx1000 commented Aug 31, 2025 via email

Introduce initial scaffold for the sources-parallel extension to enable per-source/module parallel execution in Antora. Updated playbook, scripts, and Makefile to integrate the extension, while keeping it safe/inert for future parallelism iterations.
Added a new Antora extension `antora-sources-parallel` to enable parallel-friendly builds. Includes concurrency hints (Phase 1) and an experimental per-source fan-out orchestrator for parallel execution. Added documentation, sample configurations, and supporting scripts for integration.
Enhanced the Antora parallel sources extension with a fast path for CI builds (`--no-lunr`) and updated documentation with performance tips. Improved CI workflows with better caching strategies for Antora artifacts to boost efficiency.
…on, and global index build

Added utilities to rebase relative playbook paths for proper resolution. Improved shard builds by removing Lunr extension per shard and introducing a single global Lunr index pass. Ensured global search-index artifacts are correctly copied to the final site.
Introduced the ability to set a custom `ANTORA_CACHE_DIR` and ensured directories are created as needed. Improved Lunr global index builds with a fast-path option and fallback to legacy Antora mode for robustness. Enhanced logging for cache usage and indexing steps.
Introduced a new script `build-lunr-from-site.js` to generate a global search index directly from the merged Antora site. Updated `package.json` to include the `lunr` dependency required for indexing.
…mits

Refactored Lunr builder to use minimal memory by limiting IO concurrency through `ANTORA_LUNR_IO_WORKERS` (default: 2) and capping characters per page (`ANTORA_LUNR_MAX_CHARS`, default: 200,000). Replaced custom parallel pool logic with a streamlined approach and added elapsed time logging for indexing.
Set stricter defaults for IO concurrency (`ANTORA_LUNR_IO_WORKERS=1`) and max characters per page (`ANTORA_LUNR_MAX_CHARS=60,000`). Added a simplified pipeline (`ANTORA_LUNR_SIMPLE_PIPELINE=1`) to minimize resource use by skipping heavy stemming and stopword filters. Restricted indexing to `latest` pages when applicable.
Added `ANTORA_LUNR_NODE_MAX_OLD_SPACE` to allow configurable heap size (`--max-old-space-size`) for Lunr index serialization. Updated CI workflow and `fanout.js` to set conservative default values for memory and pipeline options.
# of the "Edit this Page" link otherwise generated.
export CI = true
build-site:
build-site: build-ui prep-sources
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want building the site to clean and regenerate everything in the component repositories every time, which is what this will do AFAICT.

Copy link
Collaborator

@oddhack oddhack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per my other comment I don't want the Makefile target to completely re-do the markup transformation work every time, so holding approval back until that's addressed. Otherwise I can't really speak to the parallelization but if it's faster than what we're doing now and returns the same output, I'll be happy with it.

@oddhack
Copy link
Collaborator

oddhack commented Nov 3, 2025

Telecon: requested @gpx1000 give this a more useful PR title reflecting its main purpose in parallel builds. Will be reverted to Draft status until some further changes are made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants