docs: remove explicit cookbook section numbering

[jdhoffa]

The order is defined implicitly by the order in which it appears on the pkgdown.yml: https://github.com/RMI-PACTA/pacta.multi.loanbook/blob/3f08f0ded38803dd34937155eb16cfece32e4a30/_pkgdown.yml#L41-L46

Explicit numbering of the sections is superfluous and clunky.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 51.61%. Comparing base (3f08f0d) to head (6bda58b). Report is 1 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #262 +/- ## ======================================= Coverage 51.61% 51.61% ======================================= Files 29 29 Lines 3189 3189 ======================================= Hits 1646 1646 Misses 1543 1543 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[cjyetman]

I wonder if they even need the "Cookbook - " prefix? Somewhat clear from the section header?

[jdhoffa]

I wonder if they even need the "Cookbook - " prefix? Somewhat clear from the section header?

See the code, I had removed that too haha

[jacobvjk]

If we do this, I think it would be good to add an overview at least to the first chapter that describes what is to come, just for user orientation. While I agree that it is implicit from the dropdown in the nav bar, that is not exactly a typical way to present the contents one can expect from a document.. I think the target audience is not necessarily one that hangs out on GH a lot, so I think being a bit more explicit somewhere in the cook book does not hurt

Also, the links at the bottom of the chapters should be renamed as well then

[jdhoffa]

That makes sense. Then I will adjust.

[jacobvjk]

bit unsure why the macos check keeps failing, the same failure has recently been popping up elsewhere, but re-triggering it has usually solved it.. guess we may just have to wait and see, since it seems to be related to the latest R version

[cjyetman]

bit unsure why the macos check keeps failing, the same failure has recently been popping up elsewhere, but re-triggering it has usually solved it.. guess we may just have to wait and see, since it seems to be related to the latest R version

definitely something widespread going on: https://github.com/r-lib/actions/issues/950 https://github.com/r-lib/actions/issues/948

Looks like either an intermittent GH Actions network problem, or something to do with the latest GH Actions macOS runners being arm64 and not x86 and possibly not building R or its dependencies properly.

[cjyetman]

likely something with the macos-latest GH Action runner https://github.com/r-lib/actions/issues/948#issuecomment-2495473473

supposedly a new version (20241022.361) is currently rolling out, last run here failed with the old version (20241119.509) at 2024.11.23 17:42 GMT+1 https://github.com/RMI-PACTA/pacta.multi.loanbook/actions/runs/11973244713/job/33424388196#step:1:9

more detail likely related: https://github.com/actions/runner-images/issues/10864#issuecomment-2478461845

[cjyetman]

macOS-latest failure resolved by GitHub's latest macOS 14 runner image 20241125.556 https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20241125.556