Hi Tomek! Yes, that's the workflow I was talking about.
Doesn't it make sense to leave it enabled though? It's my understanding that workflow is useful for checking PRs that modify the Documentation to catch any introduced build errors in RST file syntax, etc. Otherwise we only detect those errors once the PR is merged and the build on the nuttx-website repo fails. Maybe we could just modify that workflow to only perform checks rather than a full build, and only when Documentation/** is modified? Matteo On Wed, Oct 16, 2024, 2:07 PM Tomek CEDRO <to...@cedro.info> wrote: > Whoops we has in fact worker enabled for rebuilting the documentation > on each commit on the nuttx repo!! > > https://github.com/apache/nuttx/actions/workflows/doc.yml > > It is disabled now :-) > > Documentation will be built on a daily basis on the nuttx-website > repo. Lets see how that improves things. > > Thank you Matteo!! :-) > > Tomek > > > On Wed, Oct 16, 2024 at 8:03 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > Actually the documentation is part of the nuttx-website repo: > > > > https://github.com/apache/nuttx-website > > > > Documentation is updated daily: > > > > https://github.com/apache/nuttx-website/actions > > > > Where did you find information on doc rebuild on every commit Matteo? > > > > For sure we may improve two things there already noted in the Issues: > > 1. Build only that branch / tag that changed, no need to rebuild all > > the documentation all the time including older releases that did not > > change. > > 2. Improve artifacts upload to the web server. > > > > Tomek > > > > > > On Wed, Oct 16, 2024 at 7:55 PM Matteo Golin <matteo.go...@gmail.com> > wrote: > > > > > > Implemented a quick fix for that. Adding more granularity based on path > > > could also be done for other workflows I think, I can spend more time > > > looking at what could be optimized later this week but hopefully this > PR is > > > enough to help cut down time! > > > > > > https://github.com/apache/nuttx/pull/14372 > > > > > > Matteo > > > > > > On Wed, Oct 16, 2024 at 1:09 PM Alan C. Assis <acas...@gmail.com> > wrote: > > > > > > > Exactly! > > > > > > > > I think if no file at nuttx/Documentation/ was modified we don't > need to > > > > compile it. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Wed, Oct 16, 2024 at 1:25 PM Matteo Golin <matteo.go...@gmail.com > > > > > > wrote: > > > > > > > > > I also think we can use the "paths" filter to only rebuild docs > when the > > > > > documentation files are changed, similar to how it is done in the > > > > > Docker-Linux workflow. > > > > > > > > > > On Wed, Oct 16, 2024 at 12:20 PM Matteo Golin < > matteo.go...@gmail.com> > > > > > wrote: > > > > > > > > > > > It may not be ideal, but would it be possible to change the > > > > documentation > > > > > > builds to only occur periodically? > > > > > > > > > > > > I noticed that the doc builds take roughly ~13 minutes, and if > they run > > > > > on > > > > > > each PR merge that will add up quickly. > > > > > > GitHub actions appears to allow scheduled actions: > > > > > > > > > > > > > > > > https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule > > > > > > > > > > > > We could trigger documentation build maybe once a week? I'm not > sure > > > > what > > > > > > the typical number of merged PRs are per week, > > > > > > but if it were around 50, that's 650 minutes per week down to > only 13. > > > > > > > > > > > > The downsides to this would be: > > > > > > a) A delay in the documentation being published > > > > > > b) Documentation changes that break the build are not caught > early > > > > > > > > > > > > From my minimal experience with Sphinx I think it might be > possible to > > > > > > circumvent issue b) by performing a less time > > > > > > intensive doc check for syntax issues in the RST files. Then > once a > > > > week > > > > > > perform the actual build and deployment? > > > > > > > > > > > > I think this would be an easy start to implement, although I > > > > acknowledge > > > > > > this particular workflow is not the main source > > > > > > of time consumption (the Build workflow is much larger). > > > > > > > > > > > > Matteo > > > > > > > > > > > > > > > > > > > > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
