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 > > >
