.github: Add label generation tool and update labels

[arvganesh]

Prerequisite checklist

• Read the contribution guidelines regarding submitting new changes to the project;
• Tested your changes against relevant architectures and platforms;
• Ran the checkpatch.uk on your commit series before opening this PR;
• Updated relevant documentation.

Base target

• Architecture(s): N/A
• Platform(s): N/A
• Application(s): N/A

Additional configuration

Added update_labels.py, a tool to automatically update the files in .github/labels with configuration of latest labels from Github.

It only has one external dependency, ruamel-yaml, which is a more powerful derivative of PyYAML for interacting with YAML files.

Description of changes

Update labels in .github/labels to match the current state of the repo.

To aid with this process in the future, I also wrote a tool (update_labels.py) to automate the majority of this process. It queries this endpoint in the GithubAPI, grabs the relevant data, and updates the YAML files in .github/labels.

GitHub-Fixes: #1283

[craciunoiuc]

Hey @arvganesh

This initial version looks really good, left you some comments.

Can you squash you commits and leave only two:

1. .github/scripts: Add label generation tool
2. .github/labels: Update labels to track latest staging

You will also need to add commit message bodies for each to describe the changes. (in order for the checkpatch check to pass)

[craciunoiuc]

In a separate PR, if you want, we can also add a workflow that runs on pushes (or weekly) and checks if labels changed and updates them automatically.

[nderjung]

Hi @arvganesh! Thanks for this contribution. We use an external tool called governctl to do the heavy lifting in terms of interacting with GitHub's API, performing operations specifically on the Unikraft core repository as well as organization-wide repositories and teams.

In order to prevent too many tools, scripts or programs dotted all over the place, I suggest looking at how label synchronization can be accomplished with this tool under a new subcommand governctl labels sync.

One thing to note is that these label config files are in fact meant to work in the opposite direction: their static declaration should dictate GitHub's state of labels (aka "Infrastructure as Code"). This means that labels should be updated from the repo and not the other way around.

I think this particular issue can be kept nearly as-is sans the introduction of the python script, changes to descriptions and changing the hex color values.

For direct changes to the labels, please:

• Ensure all color attributes are quoted, lowercase and include a pound (#) symbol i.e.: "#1d76db" is better vs. 1D76DB. This prevents the diff from needless changes;
• Only change the description if it is a better representation of what the label is intended;
• Remove libx/posix-unisocket;

Thanks!

[arvganesh]

Hi @nderjung. Thanks for getting back to me! Had a few follow-up questions:

Re: governctl labels sync, are you suggesting that I should look into adding the label generation code to governctl?

Re: The changes in this PR, there were many label files that were "created" (i.e labels were on GitHub but not in ./github/labels). Since you said the contents of .github/labels are the ground truth, should I revert any new label files that were created?

[nderjung]

Re: governctl labels sync, are you suggesting that I should look into adding the label generation code to governctl?

Yes.

Re: The changes in this PR, there were many label files that were "created" (i.e labels were on GitHub but not in ./github/labels). Since you said the contents of .github/labels are the ground truth, should I revert any new label files that were created?

The new libraries we can keep. There are also changes which need to be reverted:

• There are additions and deletions which represent re-ordering of libraries. E.g. bug/fix, lifecycle/stale, lifecycle/rotten, priority/low, etc. Please double check all entries and please keep their order.
• A lot of descriptions are changed, I assume because they were taken what GitHub has. Having gone through the list, I think the best approach is to take the longer description. E.g. "Issues and PRs related to Linux Userspace platform" vs "Unikraft for Linux Userspace", the former is better.

Thanks!