A static site generator for making documentation sites from one or more versioned content repositories.
No matter how many git repositories you use, Antora can retrieve and aggregate all the content from them to assemble a documentation site.
Since documentation files can be stored in separate repositories, the teams that maintain them can use the administration policies, version schema, and release schedule that works for them.
Use branches to version documentation just like software. Antora can find repository branches and assemble the files in each branch into a versioned documentation collection. Antora also knows how to ignore branches you don’t want published.
Antora can collect files from a combination of local, remote public, and remote private repositories over any protocol supported by git.
With an Antora playbook, anyone can easily assemble and generate a documentation site. A playbook is a straight-forward set of concise instructions that tell Antora what documentation to assemble, where to find it, and what UI to apply to it.
Just point the Antora CLI at your playbook to configure and execute the default site generator. Out comes your site!
With Antora’s playbooks, you can control which versions of the documentation get published to a site. You can even tell Antora to use uncommitted changes when generating the site on a local machine.
Antora features an open architecture. Despite providing an opinionated default site generator, you’re free to reuse the core components to assemble your own custom generator pipeline.
Antora automatically adapts a docs site to its publishing environment. Whether the site is published locally, to revolving testing, QA, or staging environments, or to an alternate URL for a campaign or event, the site is fully functional. This environment portability is possible because Antora’s cross referencing system isn’t based on a hardcoded base URL or system path.
Mark up content with AsciiDoc’s lightweight yet comprehensive syntax.
AsciiDoc’s extensive feature set is available right out of the box with Antora. There’s no need to find, install, and manage plugins, extensions, or scripts to add basic capabilities to the syntax.
Documentation written with AsciiDoc works with all of the software and tools in the Asciidoctor ecosystem. You don’t need to worry about incompatible syntax or lost functionality.
Write and preview AsciiDoc with text editors and IDEs like Atom, Brackets, and IntelliJ. And GitLab and GitHub render AsciiDoc files right in the browser.
Custom syntax our output transformations can be added as discrete extensions with Asciidoctor’s extension API.
Antora’s core developers help lead the Asciidoctor organization, home of the AsciiDoc syntax and Asciidoctor, the AsciiDoc processor. Due to this direct relationship, Antora is always in sync with AsciiDoc and Asciidoctor features.
It doesn’t matter where you publish your documentation site — on a local machine, a staging environment, or a production environment — the page-to-page cross references always work. That’s because Antora’s page referencing system isn’t coupled to filesystem paths or URLs.
A site’s navigation is described by one or more AsciiDoc lists that are stored alongside your documentation files. Links are added using the same cross referencing syntax used in the pages themselves.
Add normal text, images, icons, and external links to the navigation. Order and nest the links in the arrangement of your choice.
Site UIs are stored in separate repositories so that developing, testing, and publishing new or updated themes has no impact on your documentation files or their repositories. Antora retrieves the specified site UI just like it fetches the content files from their repositories.
Web teams can use their preferred repository structure, development workflow and release schedule since the site UI isn’t stored with the documentation.
Switch between site UIs just by changing the UI address in the playbook.
A page’s URL is derived from its filename, yet still isolated from its full filesystem path.
Routes and redirects can be specified at the site, component, version, module, and page level.
Add and remove metadata at the site, component, module, and page level using AsciiDoc attributes.
Assign taxonomy types and values at the site or page level.