Adds bits to check automatically PRs for trivial mistakes

[jeandet]

I would like to propose the idea to check PRs with CI so we get a feedback quickly and this also ensures trivial mistakes won't be missed by humans.
So far, only checks for yaml validity and correct usage of keywords in projects but I would be happy to add more and improve the script.

I've run the script locally and here is the output:

python3 .github/workflows/pr_checker.py -d
Unlisted keywords for project pySPEDAS: {'data', 'space physics', 'heliophysics', 'magnetospheric physics'}
Project AFINO has no keywords
Unlisted keywords for project GeospaceLAB: {'data_containe'}
Unlisted keywords for project solo-epd-loader: {'data', 'space physics', 'heliophysics'}
Unlisted keywords for project space-packet-parser: {'python', 'data encoding', 'data manipulation', 'space packet protocol', 'data transformation', 'data decoding', 'packet parsing', 'xtce', 'binary data', 'university of colorado', 'lasp', 'packet inspection', 'data extraction', 'data processing', 'space data systems'}
Unlisted keywords for project Speasy: {'data', 'space physics', 'heliophysics', 'magnetospheric physics'}
Unlisted keywords for project NDCube: {'data manipulation', 'visualization', 'container objects', 'astrophysics', 'heliophysics', 'data', 'n-dimensional'}
Project aidapy has no keywords
Unlisted keywords for project geopack: {'space physics', 'heliophysics', 'magnetospheric physics'}
Unlisted keywords for project sunraster: {'spectral'}
Unlisted keywords for project irispy-lmsal: {'spectral'}
Unlisted keywords for project lofarSun: {'LOFAR', 'Solar_radio'}

[sapols]

Hey this is sweet! Thanks so much for taking the time to put it together. I'm not well-versed in GitHub Actions yet so I hadn't tried anything like this, but I always wanted to. Just checking keywords is a good start, and now we'll have somewhere to add new checks in the future!

I pushed a few changes that fix the errors it found. For the most part there were obvious replacements from the taxonomy to use. In some cases I deleted keywords I didn't like, and in others I added keywords I did like to the taxonomy.

I say we go for it. But first, I just want to make sure I fully understand how this works: Once merged, will this be active for every new PR simply by virtue of having that PRs.yml file inside .github/workflows? Is that really all there is to it?

[jeandet]

@sapols GH basically reads all yaml files in .github/workflows, then the on keyword tells GH wen you want the following yaml file to be "triggered".
I also thought about adding a project structure check, ensuring that all required fields are set and not unknown ones exists, I'll add this into another PR later.

[sapols]

Ah gotcha, so it's not the filename but that on keyword. Makes sense, good to know.
And yeah that project structure check sounds like good low-hanging fruit. Thanks again for offering to do that.

If you're happy with this, I'll go ahead and merge this PR. Then you can open a new one whenever you get around to the project structure check. 👍

[jeandet]

@sapols, yes, you can merge :).