Add support for GitLab repositories about verto HOT 8 CLOSED

A couple of notes from trying to implement this:

• the graphql-js library is for building a GraphQL server, not client. We decide to simplify things as much as possible by making a direct POST call to the GitLab GraphQL enpoint (using axios)
• the list of projects/repositories is hard-coded inside of the firstissue.json file. We will have to change that file to contain github_repositories and gitlab_repositories
  • to improve even further we might even split into this format to also allow labels definition for each source

    {
         "gitlab": {
               "repositories": [...],
               "labels": [...]
          },
         "github": {
               "repositories": [...],
               "labels": [...]
          }
    }

• we will need to extract the logic that iterates over the set of repositories into its own function then call it twice, one for github_repositories and one for gitlab_repositories

from verto.

Hi @nickveenhof, thanks for opening the issue!
If you can update the data generation script to be able to handle GitLab repositories, that should do the trick.
Feel free to give it a try!

from verto.

I did some preparation and I believe this graphql query should get us going. It needs to be implemented in typescript, preferably with the use of https://github.com/graphql/graphql-js as that library is already available in node-modules due to the use of the GitHub Octokit.

The query lists the first 100 projects that have issues with one of the 3 potential labels. GitLab itself uses "Quick Win". It then lists the 10 most recent issues with that label. The code should iterate over this list and transform it in the format the project expects

Missing: The project license, I believe everything else needed to get this up and running is present

{  
  projects(
    first:100
    withMergeRequestsEnabled:true
    withIssuesEnabled:true
    sort: "stars_desc"
  ) {
    nodes {
      name,
      starCount,
      openIssuesCount,
      lastActivityAt,
      webUrl,
      languages {
        name
      },
      topics,
      lastActivityAt,
      description
      issues(first:10, or: { labelNames: ["quick win", "good first issue", "help wanted"]}, state:opened,sort:UPDATED_DESC, confidential:false) {
        nodes {
          webUrl,
          userNotesCount,
          title,
          createdAt,
          labels { 
            nodes { title }
          }
        }
      }
    }
  }
}

You can test it out through https://gitlab.com/-/graphql-explorer

from verto.

Hey @nickveenhof, thanks for the update. Your approach is sound. You have my blessing.

from verto.

@zillemarco Thinking of the fact that there are many GitLab instances with public projects, so it would be good to take that into account if we can with simpler conventions? Can the key be gitlab.com & github.com? That way we allow, potentially later, self-hosted gitlab instances and/or GitHub enterprise (although I don't know many in the wild) to add their projects as well. Alternative is to make sure the url is added.

As to the labels, I'd keep that a global key as the query is OR anyway for both GitHub & GitLab

from verto.

Yeah, I thought about it after posting that and I think a better schema might be somewhat like this:

[
    {
        "provider": "github" | "gitlab" | ...
        "source": "https://github.com" | "https://gitlab.com/" | ...,
        "repositories": [...],
        "labels": [...]
    }
]

This way we might expand to even more providers (bitbucket and others for example).

I would definitely like to hear what @lucavallin thinks about this before though 🙂

from verto.

@nickveenhof @zillemarco I like the idea of potentially being able to support any repo anywhere! The structure @zillemarco looks good to me. We should also add some logic to the UI so that we can display the GitHub / GitLab logo on each item, but that's for later. I say let's go with the the structure detailed in the comment right above ^.

from verto.

Closed by #171.

from verto.