Skip to content
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

Merged
merged 11 commits into from
Feb 24, 2025

Conversation

wenzeslaus
Copy link
Member

@wenzeslaus wenzeslaus commented Feb 19, 2025

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.

Build core and addons, then create mkdocs site as an artifact. Ignore errors with addons.
@github-actions github-actions bot added the CI Continuous integration label Feb 19, 2025
@echoix
Copy link
Member

echoix commented Feb 19, 2025

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.

@wenzeslaus
Copy link
Member Author

Any opinions on the script from addons? Shoud we just start from scratch here?

@echoix
Copy link
Member

echoix commented Feb 19, 2025

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

@wenzeslaus
Copy link
Member Author

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).

@wenzeslaus
Copy link
Member Author

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 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.

They would share the same triggers and purpose.

Yes, on the other hand, they have different build times are requirements, so I guess you could argue both ways.

The main reason of this workflow isn't really mkdocs, but the documentation/documentation site.

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
@wenzeslaus wenzeslaus marked this pull request as ready for review February 20, 2025 05:04
@wenzeslaus
Copy link
Member Author

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.

Copy link
Member

@echoix echoix left a 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?

@wenzeslaus
Copy link
Member Author

Another question: what is the time impact, and the impact of building addons on every PR?

2.5 min, total time of this job is 9 min

image
image

Copy link
Member

@echoix echoix left a 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

@echoix
Copy link
Member

echoix commented Feb 23, 2025

Seems to have the same problem as conda-forge/sqlite-feedstock#130

@wenzeslaus wenzeslaus merged commit a31e4d7 into OSGeo:main Feb 24, 2025
29 checks passed
@wenzeslaus wenzeslaus deleted the build-mkdocs-in-ci branch February 24, 2025 02:59
@github-actions github-actions bot added this to the 8.5.0 milestone Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous integration docs
Projects
Development

Successfully merging this pull request may close these issues.

2 participants