site-pr.ymlfiles within the master documentation build project, but the bigger issue is, that PRs usually would be triggered from "downstream" projects where the actual content lies, potentially even from multiple ones.
@gmarpons I didn’t consider that perhaps the reason why the solution you proposed isn’t working for me is because of a version incompatibility. We are currently still running Antora 2.0
@jaredmorgs Yes, I think you need at least version 2.1. The functionality added in this issue is relevant to my experiment: antora/antora#430.
master(or the specified branch) only. If your Antora setup is a "local" repo that involves multiple branches for doc content, you need to run a script that performs a full clone.
diff. You should only see differences in the "generator" meta tags for the HTML files (the sitemaps will have new timestamps).
It’s just the general question how to add an additional page to Antora UI that is NOT based on .adoc
It's possible to add a completely static page with no templating using the static_files field of ui.yml. However, I'd like to see a way to add a page that does use templating without having to have a corresponding .adoc file. It will require some thinking, but it's something we could achieve.
Hey, quick update: The way @djencks_gitlab described it works :) I Added an empty .adoc file with just title and :page-layout: swagger and as I added this layout to UI before, it immediately worked
Indeed, this is the way to do it today.
Is it possible to point to attachments that are stored in an attachments folder that's not in the same module where the link is being created?
Not yet. That's an open feature request.
Is there a way to setup CI to build PR branches automatically for viewing?
Netlify supports this out of the box. Couchbase has it enabled https://github.com/couchbase/docs-ui/blob/master/netlify.toml (though that example is for the UI, but it's the same thing)
I haven't used component attributes so far.
It's new in Antora 2.3 (alpha). They are scoped to the component version, though in the UI model the attributes from the latest component version get hoisted to the attributes for the component overall.
So ideally I'd prefer to have a way to define the attributes in such a way where the components are in repo A but without having to explciitly include a file in each asciidoc page.
that's exactly what has been implemented in 2.3.0 (alpha)