Docs and Web: Add to the master branch and build with each push

[zacikpa]

In this PR, I propose to move the webpage files from the gh-pages to the master branch. The webpage (preview at https://zacikpa.github.io/tuned/) now contains a link to the documentation (preview at https://zacikpa.github.io/tuned/docs/manual.html), which would be automatically deployed with each push to master.

The documentation of plug-ins and built-in functions is built from code docstrings.

The PR contains some additional refactoring of TuneD built-in functions, see the individual commits.

[zacikpa]

@yarda, technically, the static webpage files could be kept in the gh-pages branch, but the workflow itself should be in master. Let me know what you think is appropriate. Personally, I would prefer to have everything in master and get rid of the large files (i.e., fonts).

[zacikpa]

I changed my opinion: it is probably neater to keep the static files in gh-pages. I updated this PR to pull the files from there when building the website.

I also opened #765 which should be merged alongside this PR. When the PRs are merged, the repository also needs a manual update of the settings to make it build the website using the workflow.

[zacikpa]

I did some minor changes to the docs themselves, e.g., updates from yum to dnf. I also noticed that downstream RHEL docs diverged considerably from these - I don't think it's a blocker for merging this, but we should likely discuss the future of these upstream docs. I'd be personally inclined towards making them distinct from the RHEL docs and generating as much doc content as possible from the source code.

[yarda]

CentOS 7 CI failure is unrelated and was already fixed.

[Fothsid]

LGTM, though revnumber/revdate needs to be changed for the actual current release (and a rebase would be nice), or maybe introduce a way to pass down the version from the spec to the doc during build.

[Fothsid]

Is there any nice way to sync actual tuned version and the version here in the doc?

[zacikpa]

Not that I'm aware of.

[yarda]

What about:

--- Makefile	2026-03-16 15:21:55.344066816 +0100
+++ Makefile.new	2026-03-16 15:17:10.926639024 +0100
@@ -1,9 +1,12 @@
 .PHONY: clean
 
+DOCVER=$(shell cd ../..; $$PYTHON -c 'import tuned.version as v; print(v.TUNED_VERSION_STR)')
+DOCDATE=$(shell date '+%Y-%m-%d')
+
 index.html: master.adoc assemblies/*.adoc meta/*.adoc modules/performance/*.adoc ../../tuned/plugins/plugin_*.py ../../tuned/profiles/functions/function_*.py
 	$(PYTHON) ./compile_plugin_docs.py ../../tuned/plugins plugin_ Plugin modules/performance/ref_available-tuned-plug-ins_intro.adoc modules/performance/ref_available-tuned-plug-ins.adoc
 	$(PYTHON) ./compile_plugin_docs.py ../../tuned/profiles/functions function_ Function modules/performance/ref_built-in-functions-available-in-tuned-profiles_intro.adoc modules/performance/ref_built-in-functions-available-in-tuned-profiles.adoc
-	asciidoctor -o index.html master.adoc || asciidoc -d book -o index.html master.adoc
+	asciidoctor -a revnumber=$(DOCVER) -a revdate=$(DOCDATE) -o index.html master.adoc || asciidoc -a revnumber=$(DOCVER) -a revdate=$(DOCDATE) -d book -o index.html master.adoc
 
 install: index.html
 	install -Dpm 0644 index.html $(DESTDIR)$(DOCDIR)/manual/index.html

Then it uses actual TuneD version for the revnumber and build date as the revdate which IMHO is OK for builded docs.

[yarda]

I opened #835.

[zacikpa]

Thanks for the review. Rebased and updated the revnumber/revdate.

[Fothsid]

LGTM

[yarda]

I did some minor changes to the docs themselves, e.g., updates from yum to dnf. I also noticed that downstream RHEL docs diverged considerably from these - I don't think it's a blocker for merging this, but we should likely discuss the future of these upstream docs. I'd be personally inclined towards making them distinct from the RHEL docs and generating as much doc content as possible from the source code.

In the past the RHEL docs were generated from the TuneD upstream, but currently it probably isn't the case. Also the content for RHEL seems a bit outdated and it would require some work on the doc team side, so I am OK with the current PR. In the future, if there is no more collaboration with the doc team, we could clean it up and move to the generated content.

[yarda]

Thanks, LGTM.

Maybe we could use generated revnumber and revdate, but this can be changed later.