Determine labels for checks using labels.yml, factor out common workflow utils

[AetherUnbound]

Fixes

Fixes #1195 by @AetherUnbound

Description

This PR is primarily intended to modify the pr_label_check.yml GitHub Action workflow so that it reads from the labels.yml definition rather then requiring the label groups be explicitly redefined. In order to do this, I factored out some shared functions which read in the labels and convert them to Python objects. I also factored out code in several of our workflow python scripts which would print data to both stdout and the GITHUB_OUTPUTS destinations. I had to add the PYTHONPATH environment variable to the places where we call python scripts in order to have those shared modules load properly.

The effect of this is now any labels we add to the required categories in labels.yml will automatically be added to the pr_label_check workflow!

Testing Instructions

The fact that CI passes here is sign that things are working! See the output from the adjusted actions to see that they are still outputting what they were before.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[obulat]

Why do we need both? What is stdout output used for?

[dhruvkb]

I like writing to stdout so that it's printed in the workflow logs and helps with debugging.

[dhruvkb]

LGTM, this is great. Now only if there was a way to merge .github/filters.yml into the labels file as well.

On the other hand, I see less and less utility everyday in even having a labels.yml file, considering we only have two repos now (and @sarayourfriend is already coming up with interesting ways of integrating the infra into the monorepo as well).

[dhruvkb]

Just curious, why this is necessary? Is it because of the shared functions being imported into other Python files? If so, is it better to make it a a standard Python module using an __init__.py file instead of editing PYTHONPATH?

[dhruvkb]

I like writing to stdout so that it's printed in the workflow logs and helps with debugging.

[sarayourfriend]

🆒 LGTM!