Bring evergreen ZIP files release to main repo

[axelboc]

@aplaice is it time to bring your "evergreen" release concept into the main repo?

Things to consider, off the top of my head:

• The workflow would have to run only on pushes to the main branch.
• The text of the release would have to explain a bit what it's about, what the risks are (untested, etc.), and so on.
• The README and/or CONTRIBUTING guide would have to mention it too.

[aplaice]

That is what I'd ideally want/always wanted :). However, the reasons for which I had decided to implement this in my fork rather than here still apply. (Mainly security considerations.) :

1. AFAIU in order to upload to releases the GitHub token needs the contents: write permission.

   Unfortunately, AFAIU this also allows the token full write permission to the repository (change commits/branches / arbitrarily modify history (!!)), which is not great. This still seems to be the case. (PATs supposedly have more fine-grained permissions but I understand that they're intended for user-side functionality rather than actions. OTOH it seems that it's possible to hack around this, by storing them as secrets. OTOTOH PATs seem to have the disadvantage that they're long-lived, unlike GitHub action tokens.)

2. The update releases action that I used is archived.

   I had chosen it because the code of the action was quite readable so I could check that it didn't deliberately do anything crazy (and I liked the author's attitude towards security :)), and at the time, for the semi-personal use-case, I preferred "avoiding actively malicious" over "is least likely not to have vulnerabilities".

   For anki-geo I'm not sure if these are the correct trade-offs. TBH I'd be uncomfortable using an "unsupported" GH action in production.

3. I don't have a full understanding of GH actions and tokens, so while I believe I understand what they're doing, I am not absolutely confident that I'm not opening up some vulnerabilities.

All this said, I might be too paranoid about security and convenience might be more valuable (I'd definitely be more comfortable recommending the "nightly" builds if they were in the main repo). The two worst case scenarios are probably an attacker uploading malicious files for users to download and an attacker rewriting git history. The former is still present with the current "everfresh" release, while the latter probably isn't that catastrophically bad (??) — it's easy to detect and easy-ish to restore from forks/local copies.

---

One extra problem is that the action seems to be flaky (it occasionally fails for no easily diagnosable reason, but succeeds immediately afterwards, when re-run).

---

The workflow would have to run only on pushes to the main branch.

Yes, definitely. I currently have the workflow configuration present on a single branch (update-release-github-action-experiment which I sync with anki-geo upstream manually (currently rebasing and force-pushing)), so no branch specification is needed in the workflow description itself, but yes, once/if we include it should only run on pushes to master.

Probably also run only in the anki-geo organisation, for the convenience of forkers who work from their own master branch (so they don't get their own, likely unwanted, nightlies). (It seems possible.)

---

Sorry for the essay...