CI: Update labeler’s labels

[echoix]

As promised, a little follow-up on the labeler’s labels.

Was missing imagery and raster3d.
Added patterns to match for files of a module inside a the lib folder.

Excluded RFC to not match Markdown or docs.

One of my goals was to have the docs label match when it is a docs-only PR, that could be quicker to review

[echoix]

If it's correct, add the approval and set the automerge and done!

[nilason]

How about to map the directories in scripts based on the prefix?

[echoix]

I see them now. What is the difference between those in scripts rather than in their respective folders?

[nilason]

I see them now. What is the difference between those in scripts rather than in their respective folders?

Python based.

[echoix]

And vs in the python/grass/(module type name)/ folders? There's something by about imaging and temporal there

[nilason]

And vs in the python/grass/(module type name)/ folders? There's something by about imaging and temporal there

I would leave that out.

[echoix]

And vs in the python/grass/(module type name)/ folders? There's something by about imaging and temporal there

I would leave that out.

I was trying to understand the fine-details of the project's folder structure, to know if the script folder might be superfluous, if some of the code is also tucked inside the python/grass/ folder.

[marisn]

I was trying to understand the fine-details of the project's folder structure, to know if the script folder might be superfluous, if some of the code is also tucked inside the python/grass/ folder.

I think you meant gui/scripts and gui/wxpython for modules. In the past scripts/ contained various non-C modules (mainly shell scripts). Nowadays Python has taken everything over, but they still are ordinary, independent modules, that can run without gui. gui/ contains some modules with tight integration into gui. Those would not make much sense without gui. python/ on the other hand is a python equivalent of lib/. As modules are not designed to be loaded directly into python but just executed as standalone processes, such division makes sense.
Overall GRASS has fat modules and slim library. It doesn't help code re-usability but is much easier to write.

[neteler]

Good improvement. We may revisit and fine-tune it in future after some time, as needed.

[nilason]

Looks good to me, good to go!

In case you want to fine-tune, the following may be added:

display:
  - changed-files:
      - any-glob-to-any-file:
          - display/**/*
general:
  - changed-files:
      - any-glob-to-any-file:
          - general/**/*
misc:
  - changed-files:
      - any-glob-to-any-file:
          - misc/**/*

and map the following:

• scripts/db.* -> database
• scripts/d.* -> display
• scripts/g.* -> general
• scripts/i.* -> imagery
• scripts/m.* -> misc
• scripts/r.* -> raster
• scripts/r3.* -> raster3d
• scripts/v.* -> vector

[echoix]

On a second thought, since I think the use cases for the labels could be either to help finding issues that matches a reviewer's expertises, or to eventually help out with releasing/release notes, or simply to give a high level overview of what is touched, I removed the Markdown section.

It is already redundant with the docs label, and it doesn't really bring a value to discriminate between the expertise needed. If you see a PR with only docs as a label, it's a docs only change, if it is docs and modules and a category, the PR updates the documentation of a module.

I didn't remove yet the HTML, as I didn't search yet if there is a template (like for docs) that might necessitate a web expertise. Same thing for CSS and JavaScript, these are different expertises.

[nilason]

Looks good to me, thanks!

(The "binder" and "pre-commit" parts are questionable, but CI is close enough).

[echoix]

Ya, but I wasn't able to find a better place, and it isn't "build" neither. So I falled back to "who would review this?", and it's about the same as the other code quality and building infrastructure as CI.