Multiple user support

[sc0ttkclark]

Some people working at large companies have separate GitHub accounts for personal and work. It would be fantastic to be able to run the stats for multiple users at once and have the stats add together as one.

[lowlighter]

Hi 👋 !

This seems a good idea, I can see it also working too for small teams to get collective stats rather than individual stats.

I'm not sure how much work there is to do to implement this though 🤔

I think this would mean iterating overs users and perform the adequate merging strategy depending on plugins outputs.
This part should be doable without too much trouble I guess

But there is an issue with private repositories though, how would it work ?
It is supposed to also accept multiple tokens so each account can access their private data too ?

[sc0ttkclark]

Good questions for sure, I'm not sure the best way at the moment but I wanted to note that it would be handy.

[spenserblack]

I think actions can accept arbitrary inputs, so a user's workflow could look like this:

uses: lowlighter/metrics@<commitish>
with:
  users: lowlighter,sc0ttkclark,spenserblack
  lowlighter_token: ${{ secrets.LOWLIGHTER_TOKEN }}
  sc0ttkclark_token: ${{ secrets.SCOTTKCLARK_TOKEN }}
  # spenserblack_token unspecified, use `token:` as default

If I'm wrong about that, environment variables could possibly be used (and wouldn't conflict with the username committer 😆 ).

[lowlighter]

I think actions can accept arbitrary inputs, so a user's workflow could look like this

Although it does, it prints huge warnings on the workflow by GitHub telling that it's not one of supported inputs 😅

Also internally, GitHub actions actually store inputs as environment variables, they're named INPUT_* (that's also why technically only "strings" are supported by their engine as env vars are always strings, so we do custom parsing on them), but I think if we allow wild inputs it'd be pretty tedious to iterate over all of them and may actually make it harder to maintain in the future

I guess we could change the typing of token to json (or similar) and user to array, comma-separated so it'd be possible to do the following, while still keeping retro-compatibility with current workflows:

user: foo, bar
token: |
  {
    "foo": ${{ secrets.FOO_TOKEN }},
    "bar": ${{ secrets.BAR_TOKEN }}
  }
# token: ${{ secrets.FOO_TOKEN }} would still work in this case 

Or we could also create a new token_additional option that would act as the example above, except we keep token as the primary default token.

Not sure what feels the most ergonomic 🤔

---

The main blocker I guess is that the engine (which is used by both the action and the web instance) assume that octokit instance is unique (but that'd be actually a great way to scale up web instances to support multiple tokens and increase possible requests). This part probably needs some refactoring.

Probably the best way to integrate suggested feature would be to not support private repositories in a first time, and just test public data merging on a few plugins and see how it goes 😄

[spenserblack]

As another option (definitely not the prettiest option), I've seen a few repositories just have hardcoded input_1, input_2, etc. for list-like inputs and outputs. I personally like the JSON, just throwing this out there.