Add CI workflow to synchronize with shared repository labels

[MatteoPologruto]

On every push that changes relevant files, and periodically, use github-label-sync to configure the repository's issue/PR labels according to the universal, shared, and local label configuration files.

[per1234]

Please use the version of the workflow that uses npm to manage the tool dependencies here:

https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/sync-labels-npm.md

This non-managed version was originally designed for use in Arduino's more lightweight firmware repositories, where they are not already using npm and the addition of the package.json and package-index.json might make the project less approachable to the target user.

In this arduino/setup-protoc repo, we are already using npm to manage other dependencies, so there is no addition of files. Even in tooling repositories where we weren't previously using npm, the npm managed version of the workflow is still preferred because the addition of a couple files doesn't impact the normal users at all since, unlike firmware, the source code is not the product they consume.

[MatteoPologruto]

Switched to the version of the workflow using npm and force-pushed to this branch

[per1234]

There is one remaining thing that should be done before merging this. The workflow is configured to provide a preview of the changes that would be made to the repository labels once it is installed or modified via a PR or commit to a non-default branch. You can see that in the logs here:

https://github.com/arduino/setup-protoc/runs/7918501406?check_suite_focus=true#step:10:19

 > Missing: the "phase: design" label is missing from the repo. It will be created.
 > Missing: the "phase: implementation" label is missing from the repo. It will be created.
 > Changed: the "conclusion: moved" label in the repo is out of date. It will be updated to "conclusion: moved" with color "#940404" and description "Issue/PR moved to another repository".
 > Missing: the "criticality: highest" label is missing from the repo. It will be created.
 > Missing: the "criticality: high" label is missing from the repo. It will be created.
This is a dry run. No changes have been made on GitHub
 > Missing: the "criticality: medium" label is missing from the repo. It will be created.
 > Missing: the "criticality: low" label is missing from the repo. It will be created.
 > Changed: the "topic: infrastructure" label in the repo is out of date. It will be updated to "topic: infrastructure" with color "#00ffff" and description "Related to project infrastructure".
 > Changed: the "dependencies" label in the repo is out of date. It will be updated to "topic: infrastructure" with color "#00ffff" and description "Related to project infrastructure".
 > Missing: the "type: imperfection" label is missing from the repo. It will be created.
 > Added: the "type: bug" label in the repo is not expected. It will be deleted.

Everything is as expected except for this line:

 > Added: the "type: bug" label in the repo is not expected. It will be deleted.

The repository currently has this non-standard label "type: bug". When the label is removed, it will also be removed from all the issues and PRs it was applied to, which might result in the loss of useful categorization. So it is necessary to evaluate and handle the impact of label removal before merging the PR.

You can do that by doing a search for all the open and closed issues and PRs the label was applied to:

https://github.com/arduino/setup-protoc/issues?q=label%3A%22type%3A+bug%22+

There are several possible outcomes of such an evaluation:

Label was not used

If the label was not applied to any issues/PRs then there is no impact.

Action: Proceed with removal.

Label had no value

If the label was applied to issues/PRs but that didn't end up adding anything of value to the maintenance of the repository, then removing the label will actually be beneficial.

Action: Proceed with removal.

Label is equivalent to one in the standardized set

This specific case falls into this category. We have standardized on using "type: imperfection" to mark defects because "bug" is specific to code, while defects might also occur in non-code components such as documentation. So the non-standard "type: bug" label is equivalent to the standard "type: imperfection".

Action: Manually rename the non-standard label to exactly match the standard label.

Label is unique and valuable

The shared label sets are intended to be applicable universally or to a general category of projects. Individual projects may have additional characteristics that should be labeled. For this reason, the "Sync Labels" workflow also supports a local label configuration file which is merged into the shared files:

https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/sync-labels-npm.md#project-specific-labels

You can see an example of that capability in use here:

https://github.com/arduino/arduino-ide/blob/main/.github/label-configuration-files/labels.yml

Action: Add the label to a local configuration file and add that file to the workflow, following the installation instructions

[per1234]

Hi @MatteoPologruto. Have you had a chance to take a look at the change I requested in my review? It would be nice to get this PR merged.

If you have any questions, please let me know.

[MatteoPologruto]

@per1234 I manually changed type: bug into type: imperfection. Please, let me know if there is anything else that should be done!

[per1234]

Excellent work Matteo. Thanks!