Add commit history

[MoritzWeber0]

On model level, we should have a commit history. The commit history is fetched from different sources:

• Git commits
• TeamForCapella commits (not relevant for the first version)

For each commit, we should display:

• Author (+ link to use profile, see https://github.com/DSD-DBS/capella-collab-manager/issues/1088)
• Title
• Description
• Date of the commit

[romeonicholas]

@MoritzWeber0, few questions--right now the git_instances table has types for GITHUB, GITLAB, AZUREDEVOPS, and GENERAL.

1. Do we need to worry about GENERAL? I'd probably just show a message saying it wasn't a supported type if it wasn't one of the first three, but I'm not sure if it's even being used
2. I instinctively started looking at GitHub's API first, but do you know which host is the most used? Might make sense to release support for one when it's ready and add in the others as issues come up or to refine the whole thing based on feedback

[MoritzWeber0]

@MoritzWeber0, few questions--right now the git_instances table has types for GITHUB, GITLAB, AZUREDEVOPS, and GENERAL.

1. Do we need to worry about GENERAL? I'd probably just show a message saying it wasn't a supported type if it wasn't one of the first three, but I'm not sure if it's even being used

Exactly, "General" means that users can link any supported Git repository, which follow the Git standard and can be used with the Git clients / CLI. Some jobs like T4C -> Git backups and read-only sessions just use the general Git interface and ignore the Git type.

You can just throw GitInstanceUnsupportedError for unsupported instances from capellacollab/projects/toolmodels/modelsources/git/handler/exceptions.py, this will be translated to a proper API response.

2. I instinctively started looking at GitHub's API first, but do you know which host is the most used? Might make sense to release support for one when it's ready and add in the others as issues come up or to refine the whole thing based on feedback

Gitlab is most used and also supported better than GitHub, so I'd go for Gitlab first. The iterative approach sounds good (Start with Gitlab, add other Git server types later).

[romeonicholas]

@MoritzWeber0 -- questions!

Linking to author profile: I should be able to link to a commit author's Collab profile if they used the same email for both the Collab Manager and GitLab (and just leave it unlinked with the commit author's name if not), but do we know if that's the norm for our users on production? And if so, do you think it's easier to read commit authors as their username or their actual name? ("nicholasromeo" or "Nicholas Romeo"?)

Number of branches and commits: Should we only show the primary git model branch, every git model branch, or every branch that we can see for any given model at the provided URL? For a project with 1 model and a single branch, a user on a laptop could see maybe 8 commits on screen at once. For 2 models or branches that becomes about 3ish commits each. I'm thinking primary git model revision should be open and show at least a few of the most recent commits on page load, while the other models or branches start out collapsed. Does that seem like a good start, or do you have some other specific use case you wanted?

Descriptions: Shown from page load, or only with a click-to-expand? (Descriptions not included at all in picture above.) I'm not sure what our users' commits generally look like (just titles? Important info in description?)

[MoritzWeber0]

@MoritzWeber0 -- questions!

Linking to author profile: I should be able to link to a commit author's Collab profile if they used the same email for both the Collab Manager and GitLab (and just leave it unlinked with the commit author's name if not), but do we know if that's the norm for our users on production? And if so, do you think it's easier to read commit authors as their username or their actual name? ("nicholasromeo" or "Nicholas Romeo"?)

Here, it gets a bit tricky. We don't store the email address of users yet, but we get the information from the OAuth provider and this is something that should store in our database. Email matching should be the easiest. However, when I think of the typical use cases, users can use different emails, so it might make sense to have a feature that users can add custom email addresses in the settings (of cause with email verification).

If we don't find a match, we will not link to a user profile, but still show the commit.

Number of branches and commits: Should we only show the primary git model branch, every git model branch, or every branch that we can see for any given model at the provided URL? For a project with 1 model and a single branch, a user on a laptop could see maybe 8 commits on screen at once. For 2 models or branches that becomes about 3ish commits each. I'm thinking primary git model revision should be open and show at least a few of the most recent commits on page load, while the other models or branches start out collapsed. Does that seem like a good start, or do you have some other specific use case you wanted?

For the beginning, I'd only show the branch linked to the primary Git model of each Collaboration Manager tool model. We should load the commits of all Collaboration Manager models and display them in one timeline (if we have three tool models, merge the commits of the three models in one timeline).

Descriptions: Shown from page load, or only with a click-to-expand? (Descriptions not included at all in picture above.) I'm not sure what our users' commits generally look like (just titles? Important info in description?)

Most commits have no description, some have a small description and some have a large description. I'd say that we only show it with click-to-expand.