Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add commit history #1100

Open
MoritzWeber0 opened this issue Oct 16, 2023 · 4 comments
Open

Add commit history #1100

MoritzWeber0 opened this issue Oct 16, 2023 · 4 comments
Assignees

Comments

@MoritzWeber0
Copy link
Member

MoritzWeber0 commented Oct 16, 2023

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:

@romeonicholas
Copy link
Contributor

romeonicholas commented Dec 1, 2023

@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
Copy link
Member Author

MoritzWeber0 commented Dec 1, 2023

@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.

  1. 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
Copy link
Contributor

Screenshot 2023-12-04 at 10 55 46

@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
Copy link
Member Author

Screenshot 2023-12-04 at 10 55 46 @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.

@dominik003 dominik003 moved this from To Do to In Progress in Capella Collaboration Roadmap 🚀 Dec 12, 2023
@MoritzWeber0 MoritzWeber0 moved this from In Progress to Backlog in Capella Collaboration Roadmap 🚀 May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

2 participants