DashGit - A Dashboard for GitHub and GitLab repositories. Consolidates in a single view all your open issues, PRs, review requests, branches and statuses. Combine and merge dependency updates from dependabot PRs.
Given two providers X, Y, if Y has the same token and scope than X, the GraphQL queries are the same. Avoid execute this query for Y and do not display info in the branches view. Note that statuses must be displayed in the other views.
See TestGitLabAdapter (org2/proj7 branch1). This MR has the right status (unknown), but it should have a value in branch_url, created_at, updated_at attributes.
Leveraging the existence of an update manager repository to handle the updates, add the ability to mark work items with a follow up reminder that will be stored in this repository and shown in the UI when the reminder time expires. This must support both open and closed work items.
Solution will consist on creating a java based updater by porting existing codebase. The user will need to set up a dedicated repo to act as backend to run the updater. From the UI, the selected updates will be send to this repo and then executed by GH Actions to create and merge the combined pull requests:
Port codebase to create the updater
Autoresolve conflicts in adjacent lines
Create the UI to select the updates to combine and merge (only own GitHub)
The unassigned tab is used to triage, but it includes everything that has not an assignee, even the own open issues/prs. Add some option, at least to filter out the own work items.
Motivation: Currently, the involved tab includes all open work items where the user is mentioned, among others and an indicator if there any of the notifications is unread. As there can be unread mention notifications on closed work items, it displays how many, but it does not display the content of these work items. To access these mentions we need to go to the repository, that can have many other kinds notifications (mainly in GitHub).
When running on gitlab.com, the GraphQL queries return every project that is found (up to the project limits), resulting in a low probability of finding the projects that are of interest for the user. Limiting projects by specifying membership or search gives timeouts. Therefore the only reliable approach seems to be specify a fullPaths array with the projects of interest
It seems a cache problem. If using dev tools is open with cache deactivated, the notification icons dissapear after it is read, but this is not the case when browsing without dev tools open.
Getting statuses cause intermittent exceptions when accesing fields from the GraphQL response, eg. when accesing the repository field at the projects query. It seems that the graphql response does not always guarantees the structure of the node content. Note that this does not appear when querying an on-premises instance.
This is similar to #3. A branch that has been build time ago and currently does not have a pipeline record: the branch_name is empty, that causes that clicking on the branch goes to DashGit instead to GitLab
Example: an issue where I was mentioned shows the notification at the involved tab, but if it is closed later, it will continue in notification count, but I can't see it because is not open.
A regular item that is in the assigned tab has a follow-up. If the regular item is updated with a date higher than the follow-up date, it should take the update date instead of the follow-up date.
Currently, the configuration parameter Filter if label takes the string as a single label value. Convert it into an array of values to filter work items at least one of the array labels is present. A migration will be needed.
Currently, to get some work items, more than one API call is made to the repository API. This leads to duplicate items that are filterd after being sorted by date. To support #39 and #40, we need refactor the way in which this works. Duplicate responses from api and other items (e.g. follow ups) must be merged by combining their properties according to their source.