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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

wenzeslaus
Copy link
Member

Build core and addons, then create mkdocs site as an artifact. Ignore errors with addons.

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?

Comment on lines +140 to +146
- name: Make logs available
uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08 # v4.6.0
continue-on-error: true
with:
name: grass-addon-build-logs
path: mv addons-build-dir/docs/logs
retention-days: 3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to use if: always() if you want them even if you cancel a job, or if the job fails.

The continue-on-error will allow this step to not make the job fail if it fails here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted the job to not fail if the directory is missing (which it is right now). It seems that the upload-artifact action does that by default (I mean not failing), but I'm not sure if to rely on that.

I think if: always() will be more relevant if we allow some of the addon-related steps to fail rather than having them continue-on-error like right now.

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous integration docs
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

2 participants