ci: pr-label workflow maps ci: prefix to overloaded integrations label

[planetf1]

Observed

The pr-label workflow (via generative-computing/.github) automatically applies the integrations label to any PR with a ci: conventional commit prefix. This has been the behaviour since the workflow was introduced.

Separately, integrations was also used as a hand-applied label for issues about third-party framework adapters (LangChain, DSPy, CrewAI — see #436, #447–#450 etc.).

The label taxonomy overhaul in #1096 listed integrations for deletion but it survived because the pr-label workflow depends on it. As a result, the label is now an odd one out — it does not fit the new type-label vocabulary (bug, enhancement, documentation, testing, chore) and was not discussed in the context of the auto-labelling workflow.

Expected

The ci: prefix should map to a label that reflects the intent of the new taxonomy. The current mapping conflates two unrelated concepts under one label.

Notes

The reusable workflow logic lives at generative-computing/.github/.github/workflows/pr-label.yml — any change to the mapping needs to land there (and be pinned in the mellea caller).

Raised following discussion #1096 (@psschwei's question).

[psschwei]

What about adding ci as a label for things dealing with the .github/ directory like github actions, codeowners, etc.? More generally, might it make sense to have labels for each of the conventional commit prefixes? (I think we just considered from the perspective of issues, but We probably also need to consider from the perspective of PRs and commit messages?)

[planetf1]

For issues I find it useful to be able to scan and slice/dice issues quickly when we have 100s. PRs are always smaller in number, so I think the question is what we want the tags for

• identifying issues/concerns/risks/blockages ?
• helping guide prioritization or interest as to what to review
• modifying the pipeline in some way
  ....?

[psschwei]

All I'm thinking of the pr-label job, which is already adding labels (I think needed for creating release notes?), so that we just check that we're covered there. Didn't mean to imply expanding use of labels on PRs.