New (reusable) workflow to add repository items to GitHub Projects

[koeaw]

This follows up on previous, abandoned attempts to create a workflow which allows adding of issues (and/or PRs) to GitHub Projects.

The built-in auto-add workflow by GitHub continues to only cover 1 repo for free accounts, but e.g. the APIS-RDF project is now connected to 4 or 5 repos, and it's easy to forget to manually add issues which are not covered by the built-in workflow (which means there are always issues which stay "lost" in their repos).

GitHub tokens were another blocker, I guess (?! classic PATs are extremely permissive, so I assume we wouldn't have wanted to use those) but Projects v2 have been working with fine-grained tokens for a while now.

I made this workflow reusable so other ACDH-CH projects could make use of it too if they wanted to (AFAIK there are several other GitHub projecs active within our org).

[koeaw]

I purposefully didn't include the workflow's .yml extension when linking to the doc from the README because I found this confusing/misleading.

Would suggest to remove them all (and get rid of the superfluous newlines in the list), but that's a change that should go in a separate PR.

[koeaw]

Things I'm not entirely sure about:

• if the whitespace-formatting of those descriptions which go over one line is fine like that,
• if the ${{ VAR }}-style variable formatting can actually be embedded in strings like that (like one would in e.g. shell scripts). I think I didn't come across any instances of strings being put in quotation marks at all in the GitHub workflow syntax docs...

[b1rger]

I would change GH_PROJECT_TOKEN to ADD_TO_PROJECT_TOKEN, as this is the variable name we use

[koeaw]

My reasoning behind using different names was (generally would be) to try to make variable names make a bit more sense within their respective contexts.

So for someone looking at the workflow files, ADD_TO_PROJECT_TOKEN should be recognisable as a reference to a token specific to this workflow. For someone looking at the repo's action variables and secrets, who's not been following any workflow-related developments, the name would be meaningless. They wouldn't necessarily be able to guess what exactly GH_PROJECT_* is used for either, but it could at least be a clue (hence also shared prefix for token secret + project num var).

I think it was actually the variable name in the original workflow which made me feel action secrets/vars should be a bit more helpful :P (I didn't know and couldn't guess what PAT stood for, ended up googling for it).

But I can change the name so they read the same.

[b1rger]

tested and works!

[koeaw]

tested and works!

Yay!! Very cool!

But oh nooooo, for some reason, I thought this issue only applied to classic tokens. But your tests indeed show me as the user who "added" tickets. Meh.

[koeaw]

Renamed the variable and included minor style + structural changes (e.g. RELEASE_VERSION appears to be required as well -> moved to correct section).

[koeaw]

Btw. I think this:

But oh nooooo, for some reason, I thought this issue only applied to classic tokens. But your tests indeed show me as the user who "added" tickets. Meh.

can only be solved by using a GitHub App (which needs to be created on the org level) instead of personal tokens.