-
-
Notifications
You must be signed in to change notification settings - Fork 339
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
base: main
Are you sure you want to change the base?
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?
- 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 |
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.
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.
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 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.
Build core and addons, then create mkdocs site as an artifact. Ignore errors with addons.