#178 Sync stg with prod & Upgrade to antora 3.0
Merged by darknao. Opened by darknao.
fedora-docs/ darknao/docs-fp-o stg  into  stg

Download 178.patch

Keeps staging up to date with prod

@pbokoc Any thoughts on this? I generally haven't touched the staging site.

rebased onto ef1b007c860eb53f8ed30d70e65ecffbe608df85

Added upgrade to antora 3.0.0

Does this mean that we will have to prepare the PR with fixes for all docs pages first, then merge this PR and the other PRs shortly after for everyone?

I'm not sure to understand what other fixes you are talking about.
So far, I've not seen any required fixes needed on other sub repositories, but I may have missed them as I've not reviewed everything. That's why I'm targeting a deployment on staging first, so we can see if anything needs to be fixed before going to prod.
Are you referring to a local site.yml you can find on each sub repos ?
If that is the case, this one is only used for independent local build of docs module, and is not used by the global documentation build used here.
You indeed still need to fix that file if needed, but it will not affect the build of docs.fp-o.

As far as I have tested, the changes appear to be fully compatible between 2 and 3 so we can update all docs right now to the new config and then merge this one. I'll start with Fedora CoreOS, Silverblue, Kinoite.

  • CoreOS: https://github.com/coreos/fedora-coreos-docs/pull/350
  • Silverblue: https://github.com/fedora-silverblue/silverblue-docs/pull/117
  • Kinoite: https://pagure.io/fedora-kde/kinoite-docs/pull-request/9
  • IoT: https://pagure.io/fedora-iot/iot-docs/pull-request/77

@darknao Is the antora.yml file used to generate the official docs? If yes, I think we should update it for all docs repos before we merge this one. Otherwise we can go ahead.

Yes, it is.
I think the only parameter that may be impacted by this migration is the start_page one.
By default, antora will use the index.adoc from the main (ROOT) module, unless you set it to something else and the page actually exist in the tree.
So something like start_page: ROOT:index will throw a warning during the build, and default back to index.adoc.
In this very specific case, the end result will remain the same, but if you have something like start_page: ROOT:start, it will most likely end up with a 404 if you only have a start.adoc page instead of index.adoc.

In any cases, I think it's a good idea to clean up all repos to use the correct name+extension for this setting, if it isn't already set correctly.

OK, I've made https://pagure.io/fedora-docs/template/pull-request/19 for the template.

I'm listing here all the in-flights PRs I'm making:

  • https://github.com/containers/docs/pull/13
  • https://github.com/fedora-eln/eln-docs/pull/27
  • https://pagure.io/epel/pull-request/146
  • https://pagure.io/fedora-server/pull-request/71
  • https://pagure.io/fedora-docs/flatpak/pull-request/15
  • https://pagure.io/fedora-docs/install-guide/pull-request/119
  • https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/53
  • https://pagure.io/packaging-committee/pull-request/1151
  • https://pagure.io/fedora-docs/quick-docs/pull-request/416
  • https://pagure.io/fedora-docs/release-notes/pull-request/785
  • https://pagure.io/fedora-workstation/workstation-docs/pull-request/4

2 new commits added

  • Update ui-bundle to 1.01
  • Use fixed antora version for local build

We are all set for testing antora 3.0 on the staging environment.
I'm merging this.
docs.stg.fedoraproject.org should pick up the changes in a few hours, so we should be able to see if anything breaks.
I'll give it a few days/weeks then make another PR for production deployment.

Pull-Request has been merged by darknao

Metadata