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
