Support for GitLab

[NatoBoram]

• Add GitLab backend #203

I would be nice when you can also query data also from https://gitlab.com (as option in your API). I've already filed a issue on GitLab.com for profile README.md for GitLab.

Here is a link to the GraphQL API of GitLab

• Consider combining results from from GitHub and GitLab ? #753

I was using the readme status for my account and I consider how it can combine results from GitHub and GitLab. At this time it seems this readme-stats is working just from GitHub results.

[rickstaa]

@NatoBoram, I like your feature request. However, I am not sure if it falls within the project scope that @anuraghazra envisioned. We are currently working on more pressing feature requests and bugs and are not implementing this shortly. However, if @anuraghazra thinks this is within the project scope, somebody can create a pull request for it. I will leave this issue open to check the support of the community.

[hamishmb]

Would you accept a pull request for this? I might do this one day when I have some free time.

[rickstaa]

@hamishmb I'm okay with a pull request if it does not complicate the codebase. We, however, are in the middle of a significant code overhaul; see #1633, so it might be easier to add this feature after that is done.

I, however, will leave this decision to @anuraghazra since I'm not 100% sure if adding other git sites like GitLab/bitbucket etc., is within the original project vision.

[hamishmb]

Okay, that seems fair, I shall wait for the overhaul to finish.

[rickstaa]

@hamishmb, on the second tought, the changes in #1633 are related to the SVG and, therefore, would not conflict with your proposed PR too much since they are related to the fetchers. As a result, I think you can already implement this feature to use it on your fork.

Whether the PR gets merged into the main branch depends on how much it complicates the codebase and @anuraghazra opinion. I am happy to review an implementation proposal to see if it complicates the codebase before you start to implement it.

@anuraghazra, do you think supporting other Git providers like GitLab is in the project's scope, or would you prefer we stay at GitHub?

[hamishmb]

Okay. It's probably going to be quite a while before I have the time/headspace anyway, so I'll probably still end up doing it afterwards.

[rickstaa]

@hamishmb No hurries! I fully understand. We're all maintaining this project in our free time 💪. I just wanted to check with @anuraghazra before you implemented something that we will not merge.

[hamishmb]

Oh yeah no worries all good, still good to have the information either way :)

[anuraghazra]

@NatoBoram thanks for the feature request.

But I don't think we will be supporting GitLab.
Reason being, I want to keep the stats to GitHub only and there will be other overheads in adding a new platform:

• We need to add access tokens for gitlab
• Another 2 or 3 cards to maintain
• We already have a shit ton of load in the vercel instance / serverless function

[hamishmb]

Ah okay, that's totally fair enough. Thanks for making the enquiry for me though.

[rickstaa]

@anuraghazra Makes sense! Maybe we can release the core (i.e. common) components as a core package under https://github.com/readme-stats? People can submit their cards like gitlab-readme-stats and codestats-readme-stats to be maintained under the organization. After the summer holidays, I am happy to work on github-readme-stats/gitlab-readme-stats.

[rickstaa]

Having this organizational structure greatly benefits the developability and open-source nature of the project since we have better permission management giving us the ability to have a larger team. We could also put the themes in separate repositories uncluttering the pull requests. 🤔

Proposed structure

• readme-stats (org)
  • core (common folder)
  • themes (small core themes section shown in documentation and a bigger unlisted theme section)
  • docs
  • github-readme-stats (fetcher, stats, language, repo cards)
  • gitlab-readme-stats (fetcher, stats, language, repo cards)
  • wakatime-readme-stats
  • etc.

[hamishmb]

Still doesn't solve the issue of where to run it, if your existing VM instance (or whatever it is) doesn't have any extra capacity.

EDIT: But it sounds like a good idea, for other reasons as well as for this.

[rickstaa]

@hamishmb correct it only splits the capacity over multiple Vercel instances, repositories and PATs.

[hamishmb]

Out of interest, what is PAT?

[rickstaa]

O sorry for using the abbreviation without any explanation. In this case, it refers to Github Personal Access Token (PAT). We use it in the public Vercel instance to interact with the GraphQL API (see #1772 and https://github.com/anuraghazra/github-readme-stats/blob/master/src/common/retryer.js).

[rickstaa]

@hamishmb I just created a PR to export the modules and functions from the common folder of GRS as an npm package. If #2151 is merged, you can easily create your own GitLab-based readme stats card using the github-readme-stats package.

[hamishmb]

Excellent, thanks for telling me.

I've done a little web development, so would need to learn more, but this might make a fun project someday 👍

[Zo-Bro-23]

I know this is a little old, but if #2409 gets merged, you can easily add GitLab stats, and perhaps create a PR too (maybe I will try doing it myself later on)!

[rickstaa]

I know this is a little old, but if #2409 gets merged, you can easily add GitLab stats, and perhaps create a PR too (maybe I will try doing it myself later on)!

Amazing, GitLab support would be great! 👍

[barisunsalhn]

Is there any progress on this?

[Zo-Bro-23]

It will be possible to implement after #2473 gets merged.