You are right! Worker enabled again sorry :-)
I also noticed we can remove:
1. LaTeX packages install that are really heavy:
- name: Install LaTeX packages
run: |
sudo apt-get update -y
sudo apt-get install -y \
texlive-latex-recommended texlive-fonts-recommended \
texlive-latex-base texlive-latex-extra latexmk texlive-luatex \
fonts-freefont-otf xindy
2. PDF build:
pipenv run make html latexpdf -> pipenv run make html
This will definitely save up all we can in the doc worker. I will add
PDF generation on the website repo :-)
Can you prepare PR Matteo please in pair with trigger check? :-)
Thanks!! :-)
Tomek
On Wed, Oct 16, 2024 at 8: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
> >
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
