[Feature]: Allow us to specify a file that contains custom contribution metrics

[salmonsteak1]

Description

Hey there, thanks for doing this! I'm thinking to 3D print this for my co-workers, but most of them have their contribution histories set to private within our organization. Is there a way for us to specify a file which contains our own contribution metrics? Or maybe automatically generate the model for such users if the user that is authenticated with the GH CLI already has sufficient permissions to view the contribution histories of such profiles (right now it seems like an empty contribution 3D model is generated)

Requirements

Allow us to input a file that can be read to produce custom contribution histories
or
Allow us to generate contribution histories for profiles which the current authenticated GH CLI user can view (e.g. profiles where the contribution histories are only view-able by users within the same organization)

Definition of Done

• Allow us to input a file that can be read to produce custom contribution histories / Allow us to generate contribution histories for profiles which the current authenticated GH CLI user can view (e.g. profiles where the contribution histories are only view-able by users within the same organization)
• Relevant documentation is updated
• Unit tests are updated/written and passing

Additional Notes

No response

[chrisreddington]

Hey @salmonsteak1, thanks for the interest in the project and being our first external poster to the repo! 🎉

From reading your request, it looks like there are actually two requests here:

1. The ability to include 'private contributions' as part of the skyline generation.
2. The ability to import contributions from an external file.

Ability to include private contributions as part of the skyline generation

I'm pleased to share that you can achieve the first point already today! gh-skyline uses GitHub's GraphQL API, which honours the user's 'private contribution settings' from their GitHub profile.

You can find more about that in the docs here.

Below, you can see an example of my own skyline with/without the setting applied:

Without the setting:

With the setting:

Therefore, if you ask the users to configure the setting in their profile, then I believe you'd be able to get the renders (including private contributions) that you're looking for. Does that solve the issue? This is a good action for me to add as an FAQ/explainer in the project's README, and perhaps in the CLI as well.

Ability to import contributions from an external file

Given the context above, I'm not sure there would be a need for the external file approach anymore. But please let me know what you think!

Thanks again for taking interest in the project, we'd love to any 3D printouts that you make! ✨

[salmonsteak1]

Thanks for the reply! Hmm on my end, it seems like although I was able to view my co-worker's contribution history on the web, it seems like the CLI tool is still only able to identify the public contributions. Is there no way around this apart from asking them to set their contributions to public?

[chrisreddington]

Thanks @salmonsteak1! The example I provided above would allow any user to see the contribution history (not the actual contributions themselves) to public. If you view the contribution history on my profile, it should make more sense what I mean 😄

However, I've been digging into this a bit more, and I think there may be another option. If you run gh auth status in the terminal, I suspect that the scope read:user is not present. Is that correct? I have tested it in the CLI for a colleague's profile when using that scope and have SSO enabled for the relevant org. It appears to match up with the web view when I'm logged in, compared to browsing their profile in a private browser.

You can find more details about the OAuth Scopes in the GitHub Docs. The GitHub CLI auth login command allows you to request additional scopes using the --scopes flag. So you could try running gh auth login --scopes read:user, and try re-rerunning gh skyline again to see if it gives the expected results.

[salmonsteak1]

Hey @chrisreddington, doing gh auth login --scopes read:user worked! The scope read:user was indeed not present when doing a gh auth status. Thank you for your help :)