99: Set Up GitHub Actions and Workflows

[raffaelfoidl]

Closes #99.

---

Quick facts:

• I have set up branch protection rules for main and develop (e.g. linear history, CI green, at least 1 review)
  • the rules for develop are a bit less strict, i.e. the two of us may circumvent those rules
  • for main, we would have to deliberately turn it off temporarily if we'd like to ignore the rules
• migration log:
  • issues have been thoroughly migrated (open and closed ones), including comments (excluding time logs)
  • wiki has been migrated according to your specification
  • milestones and labels have been migrated (but lowercased, as per GitHub conventions)
  • PRs could not be migrated because they were already merged
  • instead, closed issues were created for them with the label gitlab merge request, including our discussions (which might be worth something)
  • if you want to filter closed issues, but ignore merge request issues, use the query is:issue is:closed -label:"gitlab merge request" (i.e. just press the respective buttons in the GitHub UI and insert a - before label in order to exclude issues with label gitlab merge request)
  • organization administrators (you and me) might completely delete issues - so if you deem the issues absolutely worthless, we could also delete them
  • snippets have been migrated as dedicated wiki page (which is fitting because we did not use snippets as intened by GitLab, anyway )
• the grep with pearl regex for check-client did not work (neither in GitLab nor in GitHub), I had to fix it with a sh-compatible script because I did not want to be frustrated with grep and PCRE anymore
  • sh is a requirement because CI jobs don't run in bash which takes away some nice syntactic sugars
  • please note that I did not know how to express if A && (!B && !C) more succinctly in a sh-compatible way - it took me already quite some time to get it working as is - so I'd like to keep it a bit more verbose for now
  • but feel free to ask me via DM about what exactly failed (in GitLab and GitHub), why we didn't notice and what struggles I had to overcome to arrive at the current solution
• the GitHub CI is essentially equivalent to the one we had at GitLab - you can see them along with badges etc in the readme as soon as everything is merged to main. until then, you can view some past actions in the Actions tab - there you have build logs, artifacts, dependencies between jobs etc.
• I added issue templates for different kinds of tickets (bug, feature, task) along with some help text. You can try it out as soon as everything is merged to main. Until then, look at the follow-up issue #100 for an example of the task template.
  • if you absolutely hate them, we can remove them. However, I like this feature because it gives you some suggestions when formulating issues. Note, that I don't intend to have this as as guideline, i.e. that every feature must conform to at least one such template. If you just create a quick issue, just delete everything and give a short textual explanation. I just like those templates to give you some kind of structure (if you want) - in my opinion, it also helps you break everything down and think about what you want to achieve with an issue. But, as I said, you are always free to use as much or as little of those templates as you want.
• One, in my opinion, quite serious blunder on GitHub's side is that you don't have a feature like GitLab's "Create Branch" directly from an issue. That's why I have included and configured the create-issue-branch action (also have a look at the repository settings under Integrations -> GitHub Apps where it had to be activated first). It doesn't give the exact same workflow as in GitLab, but essentially achieves the same - you simply have to comment /cib on an issue. This way, we easily get consistently named (for the future and also consistent with how GitLab did it) feature branches.
• you should have been added to the organization and the @witness-org/core-maintainers team. the team simplifies managing roles and privileges for multiple people. for the witness repository, @witness-org/core-maintainers is admin which is the ultimate reason why we are able to bypass some rules for the develop branch (and why you should automatically have been added to repository, without me explicitly adding you, as a person - but because you are part of the team)
• Caveat: The only thing that could not be migrated automatically are attachments, i.e. files and images, to comments, issues and so on (it would have been possible, but only with an AWS S3 bucket as intermediary storage and I did not want to create one). I did it manually for the Wiki (obviously, it's important there), but did not do so for past/closed issues and merge requests. If you would like to have that, I kindly ask you to do so yourself (i.e. download image or file from gitlab, edit comment in github and replace gitlab file reference by newly uploaded file/image in github) - e.g. for images in closed merge requests or your UI sketches for logging workouts.

Question for you: Is there anything left we need from GitLab or was I able to migrate everything relevant? In other words, can the GitLab project be archived?

[bruggerl]

With respect to the GitLab repository, I think we can archive it. Thanks for migrating the contents!