Yes, if we disable it probably we will merge commits that will damage the Documentation/ files format.
BR, Alan On Wed, Oct 16, 2024 at 3:11 PM Matteo Golin <matteo.go...@gmail.com> wrote: > 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 > > >
