Fix broken and incorrect links in time series tutorials

GRASS GRASS user
1

Hi, I’ve been exploring the time series tutorials and found two link issues in time_series_management_and_visualization.qmd:

  1. Line 427: t.rast.univar links to t.vect.univar.html wrong tool (raster vs vector).

  2. Line 297: g.gui.tplot links to the grass83 manual which now returns a 301 redirect should be grass-stable.

Is a small PR to fix these welcome? Happy to dig in if it’s the right direction.

2

Found two more issues, this time in time_series_aggregations.qmd. Both are in the hidden setup cell (#| echo: false), so they don’t show up in the rendered tutorial, but they do break execution in the downloaded Jupyter notebook.

Bug 1 — undefined variable

Line 48 uses grassbin as a variable, but it is never defined. The other tutorials in the series consistently use the string "grass" instead, so executing the notebook currently raises:

NameError: name 'grassbin' is not defined

Bug 2 — incorrect project path

Line 55 sets:

path_to_project = "eu_laea/italy_LST_daily"

However, the other tutorials use:

"italy_eu_laea/italy_LST_daily"

The missing italy_ prefix causes the GRASS session startup to fail.

Given that there are now five related fixes in total (3 broken links + these 2 notebook issues), would it make sense to bundle them into a single small focused PR?

3

Sounds good, please submit the corrections.

1 Like
4

Done: PR #121 is open with all five fixes. Thanks for the quick response!

5

Great catch by @Valyrian-Code and quick turnaround by @neteler!

Dealing with broken links, deprecated manual paths, and hidden setup NameError bugs in interactive notebooks (.qmd / Jupyter) is a classic documentation maintenance bottleneck.

To prevent these regressions from slipping into production in the future, it might be worth setting up a automated CI/CD validation workflow inside GitHub Actions for this repository. We could implement:

  1. A lightweight markdown link-checker (like lychee or a custom Python script) to catch dead URLs and hardcoded redirects.

  2. An automated headless execution step (via quarto render or papermill) to test-run the hidden setup cells on every PR and catch runtime execution errors before they hit the users.

If the core team is open to adding this layer of automated test infrastructure, I’d be happy to write and contribute the YAML configurations to the repository. You can check out my pipeline layouts, custom automation tools, and code quality directly on my GitHub: Bohdan Betskov Portfolio on GitHub.

Let me know if you want to set up this automated safety net for the tutorials workflow!

6

I’m more familiar with lychee. How do you plan on having it configured so the links work in a PR (before being deployed), and once published, and that both configurations don’t have mistakes?

If a file is not published yet, but will be in the same PR that edits another file?

Do you plan on having a separate workflow, manage it manually, or use something like a flavor/custom flavor of megalinter?