GitHub Integration (Issues, Labels and Comments)

[vlerenc]

Story

• As operator admin (the same means we use to give the operator of the week access to all projects), I want to have a journal for a cluster (only visible by said admins), so that I build up knowledge around a particular cluster (e.g. "Owner often breaks it by running performance tests and then complains about this or that") or issue of that cluster (e.g. "Cluster VPN failed", "Checked seed VPN and found nothing in the logs, shoot VPN logs to be checked next when I have time again").
• As operator admin (the same means we use to give the operator of the week access to all projects), I want to label clusters (only visible by said admins), so that I can mark clusters as e.g. "critical" or "ignore-because-already-checked" or "performance" or "to-be-ignored".

Motivation

Help ease the work of the operator (of the week) to drop https://github.wdf.sap.corp/kubernetes/kube-docs/wiki/Operator-of-the-Week-Journal which is hard to maintain.
As long as we use the dashboard also as front-end to our self-service/canary users, we might want to hide the journal and labels from the users. Later, this distinction and double-use (self-service and ops frontend) won't be necessary anymore and the journal can be shown to the operators in general.

Implementation

As a practical and quick solution, let's use GitHub for issues, journal (in the form of issue comments) and labels (in the form of issue labels). That way we do not have to implement much on our own. We only read the data conveniently from GitHub with a technical user and delegate to GitHub for editing with the true actual/human user.

See also #5 and #33. This resolves two thirds of #8 s well.

Acceptance Criteria

• From the cluster details a new issue can be created in a globally configured Enterprise GitHub instance (later we could also support public GitHub), org and repo (later we could make all three configurable per project (default) or cluster (overwrite) as well)
• All existing issues for a cluster are shown in the cluster details
• Every issue in cluster details features:
  • Link to the issue in the GitHub UI
  • Title of the issue (possibly truncated by the technical part of the issue title that is used to identify the issue's association with the cluster)
  • Labels of the issue in their respective color (possibly dropping technical labels that are used to identify the issue's association with the cluster)
  • Description and comments in their respective order with the author's name and image
• The number of all associated issues is shown in the cluster list (especially Show All Clusters Across All Projects (can be filtered by e.g. having issues or not) #4)
• Labels (non-repeating) of all associated issues are shown in the cluster list (especially Show All Clusters Across All Projects (can be filtered by e.g. having issues or not) #4)
• Cluster list (especially Show All Clusters Across All Projects (can be filtered by e.g. having issues or not) #4) can be filtered by those with or without issues and certain labels or their absence

Definition of Done

• Knowledge is distributed: Have you spread your knowledge in pair programming/code review?
• Unit Tests are provided: Have you written automated unit tests or added manual NGPTT tickets?
• Integration Tests are provided: Have you written automated integration tests?
• Minimum API exposure: If you have added public API, was it really necessary/is it minimal?
• Operations guide: Have you updated the operations guide?