-
-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: Add workflow to build mkdocs in GHA #5152
Conversation
Build core and addons, then create mkdocs site as an artifact. Ignore errors with addons.
Can it be made a bit general where we could build all our docs, if we manage to integrate the what currently is sphinx python reference, and (doxygen) C api docs? They would share the same triggers and purpose. The main reason of this workflow isn't really mkdocs, but the documentation/documentation site. |
Any opinions on the script from addons? Shoud we just start from scratch here? |
If we are to have this in the main repo, probably to build for main and the other release branch repeatedly |
While we want to include the addons, the doc for the main repo is the focus, so the build should happen here. My question if that infrastructure script for building addons should live here, continue living in addons, or if we should just start from scratch with new code (in YAML or a separate file). |
They should definitively be integrated on the basic level of links (at least at this point) just like the HTML does: https://grass.osgeo.org/grass-stable/manuals/ links to https://grass.osgeo.org/grass84/manuals/libpython/index.html and https://grass.osgeo.org/programming8/ The artifact has actually already >100MB (>160MB unzipped), so the result will be large with all three, but then, building all here in CI would be great, so it really depends on how the upload to the documentation server is handled.
Yes, on the other hand, they have different build times are requirements, so I guess you could argue both ways.
I'll rename it, but I'll keep the scope of the PR to mkdocs. |
…ions when addons branch may not exist), rebuild keywords, rename file
This is actually in a pretty good shape. It even generates files for addons which is already better than I expected. The addon stuff is expected to fail now as it depends on updates to grass-addons, so that's allowed to fail without failing the workflow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another question: what is the time impact, and the impact of building addons on every PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still reviewing, but here's some to start with
Co-authored-by: Edouard Choinière <[email protected]>
Seems to have the same problem as conda-forge/sqlite-feedstock#130 |
Build core and addons, then create mkdocs site as an artifact. Ignore errors with addons.
I'm trying to get a rough workflow where the main part works and the addons may work. I want to continue-on-error in this step and others because they are currently failing or at least not delivering what they should.
In the meantime, #5177 and #5175 are fixing the issues I identified so far and that should be enough to remove continue-on-error here. These are now sort of chicken and egg, the other PRs fix the build, but this PR actually builds in CI, possibly showing how the other two work. We can merge them in any order and I can then go back and improve this workflow. This was my original idea before I created the other PRs.