Onboard the GitHub Action based Issue-Labeler

[jeffhandley]

These workflows replace the issue-labeler implementation that runs as a GitHub app, allowing training and prediction for the repository's labels without the need for an external service. We will decommission that service once all repositories migrate to the new implementation.

References:

• Home · dotnet/issue-labeler Wiki
• Onboarding · dotnet/issue-labeler Wiki
• FAQ · dotnet/issue-labeler Wiki

Once this is merged, we will need to run the 'Labeler: Training' workflow to train new prediction models, then 'Labeler: Promotion' workflow to promote the models into active use, and then I will disable the integration of the legacy issue-labeler app for this repo.

The legacy issue-labeler was configured to apply the untriaged label to new issues in this repository. The new Issue Labeler does not have that functionality; it exclusively handles predicting labels (such as area- labels). This PR retains the untriaged label automation and improves it by using the 1ES policy-service for automatically applying the label to new issues, unless there is already a milestone or assignee applied. That policy will also automatically remove the untriaged label when a milestone or assignee is applied, which seems to match how issues in this repository are managed. But let me know if you'd like that logic updated.

[jeffhandley]

I see from this PR itself that the legacy issue-labeler is also applying untriaged to new PRs. Let me know if you'd like to retain that behavior; if so, I can update the untriaged policy here to add that logic as well.

[NikolaMilosavljevic]

I see from this PR itself that the legacy issue-labeler is also applying untriaged to new PRs. Let me know if you'd like to retain that behavior; if so, I can update the untriaged policy here to add that logic as well.

I don't think untriaged label for PRs is necessary. I see that PRs in other repos that use GH action-based issue labeler do not get this label by default. That seems like a better model.

[jeffhandley]

Cool; then this is ready to go, @NikolaMilosavljevic.

Once this is merged, we will need to run the 'Labeler: Training' workflow to train new prediction models, then 'Labeler: Promotion' workflow to promote the models into active use, and then I will disable the integration of the legacy issue-labeler app for this repo. Let me know if you have questions or issues running those workflows.

[NikolaMilosavljevic]

Cool; then this is ready to go, @NikolaMilosavljevic.

Once this is merged, we will need to run the 'Labeler: Training' workflow to train new prediction models, then 'Labeler: Promotion' workflow to promote the models into active use, and then I will disable the integration of the legacy issue-labeler app for this repo. Let me know if you have questions or issues running those workflows.

Great! Do we need any more fixes made in other repo PRs, i.e. dotnet/runtime#115256?

[jeffhandley]

Sure; I can pull the comments and the markdown doc over into here too. Will have that here very shortly...

[jeffhandley]

Thanks, @NikolaMilosavljevic. I noticed the 'Actions' tab is not visible on this repo, so it's possible actions need to be enabled as well.

The Required GitHub Actions settings part of the onboarding page has the instructions. I'm happy to walk through that with you if you'd like.

I won't hit the merge button since I won't have permissions to configure that or run the 'Training', 'Promotion', or 'Cache Retention' workflows. After those are run once manually, everything will be automatic thereafter until you ever reach the point of needing to train the models again.

[NikolaMilosavljevic]

Thanks @jeffhandley - I've enabled actions and updated other settings to match those in the guide.