Consider moving to GitHub Actions

[owenvoke]

It might be worth moving to GitHub Actions as has been discussed previously on Gitter. We've already moved the Python client over to GH Actions in tldr-pages/tldr-python-client#105. And it would also possibly make it easier to merge the tldr-bot code into the repository which would probably be faster (using the built in integrations).

I've started work on this and there are only a few more variables that are required for it to work.
https://github.com/tldr-pages/tldr/compare/master...owenvoke:feature/gh-actions?expand=1

• TRAVIS_PULL_REQUEST, this provides the id of the pull request and is empty when triggered by a non-PR. I've had a look and most things just say to parse the GITHUB_REF env variable instead.
• TRAVIS_COMMIT_RANGE, this provides the range of commits included in the PR or push. It's used only in the deploy script commit messages.

---

Secrets can be added in the settings, and we'd need to add three as far as I can tell. It's also worth noting that GitHub Actions doesn't allow lowercase env variable names, they are case-insensitive so the script would need to be updated. 👍

• encrypted_973441be79af_key - used for decrypting the website repository deploy key
• encrypted_973441be79af_iv - used for decrypting the website repository deploy key
• TRAVIS_BOT_GITHUB_TOKEN - which looks like it's not being used (I think this was from this script)

---

It may also be good to, once we've updated to use GitHub Actions, add some scheduled workflows for tasks such as opening issues about contributor/maintainer/owner actions. See #4113 (comment) for some more information.

[MasterOdin]

TRAVIS_COMMIT_RANGE, this provides the range of commits included in the PR or push. It's used only in the deploy script commit messages.

Given the switch to "squash and merge" PR merge strategy, it looks like TRAVIS_COMMIT_RANGE is always one commit, so not sure it's valuable. If anything, I would recommend changing the message to be upload assets for tldr-pages/tldr@{{ github.sha }} (ex: upload assets for tldr-pages/tldr@e3f9c6f33ea5 -> "upload assets for e3f9c6f33ea5"). The benefit here would be that (as displayed in the example) the commit message now has a direct link within the web UI to the commit in question that generated the assets.

encrypted_973441be79af_key - used for decrypting the website repository deploy key
encrypted_973441be79af_iv - used for decrypting the website repository deploy key

You could just embed the key as a github secret and only use it on pushes to master, and not have a secrets file embedded into the repo.

[zlatanvasovic]

@MasterOdin Even though that true in 95% of the cases, sometimes we use rebase and merge too.

[MasterOdin]

Fair. I suppose a follow-up question though would be "is anyone using those commit messages in some way, and want to know what the range of commits are, or would they be fine only knowing the HEAD commit SHA?"

[owenvoke]

Thinking about this, I'm not sure that commit range is actually that useful for this. 🤔

In the website's commit history, you'd be able to see the commits that it is between even with just the current commit. I think it would probably be fine to use the following instead:

git commit -m "[GitHub Actions] uploaded assets after commit ${GITHUB_SHA}"

It still bugs me that there isn't a GITHUB_PR_ID variable as that's such an obvious one to include, but looks like we can use the github.event.number variable. 🤷 I'm going to work on finishing those changes and then open a PR.

---

Opened PR #4125