Doxygen 1.9.7 breaks our urls, see issue #347. Let's put a check for the
doxygen version into our CI build so that if our base distro updates beyond
that, the CI fails and we know we have to build doxygen from scratch or
update to some other version that's supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Upload the doxygen output as artifact from the linux build and use that from
the pages job where we combine the static website with our newly build HTML
docs. The GitHub actions/download-artefact doesn't work across workflows so
we use the other popular one that can do this. The rest of the job is
basically copy/paste from the "Static HTML" example GitHub provides.
To make this useful as drop-in replacement, replace the one fixed link to the
API docs a relative one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Doc URLs may change with time because they depend on Doxygen machinery.
This is unfortunate because it is good practice to keep valid URLs
(see: https://www.w3.org/Provider/Style/URI.html).
I could not find a built-in solution in Doxygen, so the solution proposed
here is to maintain a registry of all URLs and manage legacy URLs as
redirections to their canonical page.
This commit adds a registry of URLs that has three functions:
- Check no previous URL is now invalid.
- Add aliases for moved pages.
- Generate redirection pages for aliases. The redirection works with
a simple <meta http-equiv="refresh"> HTML tag. See:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#http-equiv
This commit also initialize the URLs registry with current pages and some
redirections needed after recent documentation refactoring.
Finally, the CI is updated to catch any change that invalidate previous
URLs.
A test case failure usually also triggers valgrind leaks, sifting through those
to find the actual test failure is painful. So let's separate the tests and run
them separately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it easier for contributors to check if their code runs correctly
without having to file a PR.
The Mac and Windows workflows are a bit more involved, so let's keep those on
pull requests only.
"main" is a bit non-descriptive, let's name them after the platforms we run them
on. Splitting them up allows us to be less selective on how we run the various
workflows, e.g. always running the linux one.
Pierre Le Marre
Peter Hutterer
Ran Benita