add labeler workflow

[Artturin]

Automatically add labels to pull requests based on the files they touch.

If a label exists in Nixpkgs then use that instead of making a new one.

https://github.com/actions/labeler

[fricklerhandwerk]

Triaged in Nix team meeting on 2022-11-25:

• have to discuss the labeling convention in detail, but agree that we want this in principle

-> to review

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-11-25-nix-team-meeting-minutes-11/23601/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-12-nix-team-meeting-minutes-16/24119/1

[fricklerhandwerk]

Discussed in Nix team meeting 2023-01-02:

• @fricklerhandwerk: should discuss it again together, given new information on the labelling scheme used by Nixpkgs
• @thufschmitt: this is relevant for maintainers and contributors, and we should delegate to someone to make a proposal giving more context and reasoning

---

@Artturin, since no one on the Nix team currently has much time to actually deal with the subject in depth, but we agree that developing a process involving labels would help us be more productive - would you like and do you have the capacity to help out here?

Here's what this could entail:

The Nixpkgs workflow is not documented anywhere except for your prior comment. Could you solicit input from maintainers and give more details how the labels are used exactly? And maybe gather some intelligence on other projects (on GitHub or similar) and their labelling schemes and workflows? Then make a PR to sketch rationale, alternatives considered, the proposed system, and how maintainers and contributors should make use of it. It should be lightweight to start with, and extensible with growing needs. I suggest the team would try out ideas from the proposal as we go, and merge it into the maintainer handbook or contributor guide once we settle on something that works.

I imagine that using more structured labels could help keeping an overview, given the procedure is well-documented and followed regularly. They have the advantage that state changes are logged by GitHub, as opposed to when they are moved around the GH project board where the team currently keeps track of issues and PRs.

@NixOS/nix-team Until then I suggest we use the existing labels and merge the automation itself.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-01-02-nix-team-meeting-minutes-20/24403/1

[fricklerhandwerk]

@Artturin are you still interested in pursuing this?

[Artturin]

suggestions applied

here's the old labeler.yml incase its needed

# if a label exists in nixpkgs then use that instead of making a new one

"8.has: changelog":
  - /doc/manual/src/release-notes/*

"8.has: documentation":
  - doc/manual/*
  - src/nix/**/*.md

# does not exist in nixpkgs
"8.has: test":
  - tests/**/*

A another reason to use the same labels as nixpkgs (for issues at least) is that moving a issue uses the same labels when moved from nix to nixpkgs and vice versa
see https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Abug which are all moved from nix to nixpkgs

[Ericson2314]

We discussed this in the Nix team meeting today and agreed we want to do this. Decision: Merge.

We were going to do so after this CI failure went away, but I just noticed what I think is a typo. @Artturin can you fix this?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-13-nix-team-meeting-minutes-40/26309/1

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/this-month-in-nix-docs-1-march-2023/26913/1