WIP: Add github contributors to website footer

[jsheunis]

See: https://github.com/datalad/datalad.org/issues/103

This PR adds github contributors to the website footer, as well as a github action to update these contributors once daily.

This is the process:

1. github action runs on a cron schedule
2. checkout master
3. run a shell script that:
   • loads existing contributors (each with login and avatar url) from json file
   • loads static list of repositories to check from txt file
   • makes a curl request for all contributors of a repository
   • prunes the response objects to only include login and avatar fields
   • merges the array of objects with the array of existing contributors
   • write merged list to existing json file
4. commit and push changes file to master
5. run the rest of deployment steps to push changes to gh-pages branch (same steps as the on:push action)

TODO:

• [x] add full list of repositories to txt file

[yarikoptic]

Following up on my comment during meetup: please checkout https://github.com/con/tributors which we use in datalad "core": https://github.com/datalad/datalad/blob/master/.github/workflows/update-contributors.yml . Ideally such workflow/action should be provided just by a parametrized action to avoid duplication. I think @vsoch started to work on one (in https://github.com/con/tributors/pull/2) at some point.

edit: you can checkout sample PRs that workflow sent among https://github.com/datalad/datalad/search?q=tributors&type=issues , see e.g. https://github.com/datalad/datalad/pull/5860/files

[vsoch]

We also have an example in https://github.com/USRSE/usrse.github.io/blob/main/.github/workflows/update-contributors.yaml !

[jsheunis]

@yarikoptic If I understand the tributors tool directly, it operates on a specific repository and collates all contributors from various sources (all-contributors, zenodo, etc) into the .tributors file for that repository. I think in the current use case of the website, this is not directly applicable since for the website I want to merge all contributors to the DataLad ecosystem from various repositories. What would make sense to me is to keep the current action, but to also inspect .tributors files in case they are available in repositories being inspected (since the .tributors files might contain more contributors than what is available via the GitHub API).

A second point is that I also want to fetch the respective GitHub avatars of contributors, which doesn't look like it's available via tributors in its current state.

[yarikoptic]

If I understand the tributors tool directly, it operates on a specific repository

IIRC - yes! that was our primary use case(s)

and collates all contributors from various sources (all-contributors, zenodo, etc) into the .tributors file for that repository

somewhat... initial need/goal was to avoid manual curation of multiple lists of contributors and be able to assist e.g. in creating a .zenodo.json from information present in all-contributors and vise versa. So .tributors became "common exchange store".

I think in the current use case of the website, this is not directly applicable since for the website I want to merge all contributors to the DataLad ecosystem from various repositories

indeed a bit different goal, although I guess could be developed to be supported by con/tributors since could be common enough. Up to you either to do that or not.

A second point is that I also want to fetch the respective GitHub avatars of contributors, which doesn't look like it's available via tributors in its current state.

well, we indeed somewhat rely on all-contributors for avatars matrix within README.md . you could as well just start using it here, it would populate those urls in .all-contributorsrc (JSON) and you could just use them in the page the way you like it. But that would not be fully automated etc, so indeed for the total "wall of contributors" the easiest would indeed be just some script to go through the list of contributors to a list of organizations/repos once in a while . Note, some might be odd though (no picture, just pictograms like the one for https://github.com/kyleam) so you would like to get a name along, for that a separate query might be needed (? so probably result of which should better be cached on disk between runs).

[jsheunis]

Thanks, good to understand the delineation and overlap of these use cases.