search

badges / shields

Concise, consistent, and legible badges in SVG and raster format
https://shields.io
Creative Commons Zero v1.0 Universal
23.59k stars 5.49k forks source link

Add submodules support on GitHub through `graphql` api #9996

Open Dynesshely opened 7 months ago

Dynesshely commented 7 months ago

:clipboard: Description

Currently, more and more projects use git submodules to split the project architecture, leaving an almost empty main repository (almost only references to submodules)

However, when counting data such as repo size/code size/comments, shields does not take the data of submodules into consideration.

Currently, GitHub GraphQL Api can already query submodules under a warehouse. As long as the recursive search (specifying the front depth) is required, a submodule tree of the warehouse can be constructed. The shields (repo size, etc.) mentioned above can be more accurate. (Of course, we may have to verify that the repositories belong to the same owner)

Take my own repo for example:

image

Dynesshely commented 7 months ago

For some shields that can introduce this function, we can add (bool) includingSubmodules argument.

chris48s commented 7 months ago

A slight issue here is that the submodule object isn't a full repository object. It only exposes quite a limited number of properties.

https://docs.github.com/en/graphql/reference/objects#submodule

As far as I can tell, things like size, languages etc can't be fetched for all submodules in a single query, so we'd have to make a second round-trip to fetch the details for submodules. With the GraphQL API we could at least query the data for all submodules at once in a second query.

I think I'd want include_submodules to be an optional param which is off by default.

Which badges are you thinking this would apply to?

Dynesshely commented 7 months ago

A slight issue here is that the submodule object isn't a full repository object. It only exposes quite a limited number of properties.

https://docs.github.com/en/graphql/reference/objects#submodule

  • branch
  • gitUrl
  • name
  • nameRaw
  • path
  • pathRaw
  • subprojectCommitOid

As far as I can tell, things like size, languages etc can't be fetched for all submodules in a single query, so we'd have to make a second round-trip to fetch the details for submodules. With the GraphQL API we could at least query the data for all submodules at once in a second query.

I think I'd want include_submodules to be an optional param which is off by default.

Which badges are you thinking this would apply to?

As you said, it does require a second query to get the exact information, but I think it is worth it. Of course, in order to relieve the pressure on the server, this attribute should be turned off by default.

I think this property can be applied to the following shield first:

chris48s commented 7 months ago

I think I agree with the first 3 :+1:

Not sure about stars. If I make a repo and pull in https://github.com/freeCodeCamp/freeCodeCamp as a submodule, my repo now has >300k stars? :smile:

Dynesshely commented 7 months ago

Not sure about stars. If I make a repo and pull in https://github.com/freeCodeCamp/freeCodeCamp as a submodule, my repo now has >300k stars? 😄

We could only count submodules' stars when they are owned by same owner, which could be better.