-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Add GitHub API integration #3
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
На текущем этапе мне в целом всё окей, но давай синхронизируем чё дальше делать.
Как я это представлял:
- В
ready
плагина мы собираем все коммиты репозитория через git log - Генерируем три списка коммитов: новые (которых нет в кеше), просроченные (которые есть в кеше, но старше чем ttl), нормулёк (в кеше и не просроченные)
- Обходим новые и добавляем в кэш, а потом просроченные и обновляем их кэш (оба списка обходим пока не упираемся в лимиты, если упёрлись — просто бросаем обход)
- Если находим коммит, у которого нет гитхаб-профиля, то кладём в кэш commit.author.name как name, а вместо ссылки профиля ссылку на коммит на гитхабе, например.
- В
extendPage
c помощьюgit log --follow $page.filePath
находим все коммиты связанные с этим файлом и вытаскиваем из кэша данные по контрибьюторам. Генерим список из уникальных контрибьюторов, кладём его в $page
Нужно покопаться и учесть:
- Нужна функция (
profileResolver
?), которая получаетArray<GitCommit>, RepositoryData
и на выходе выдаётArray<Record<CommitSha, Profile>>
— так мы сможем легко переопределить её на гитлаб-гитхаб-гит-етс - Нужно посмотреть сколько за раз можно засунуть в апишку гитхаба коммитов и чанковать запрос
- Нужно научиться обрабатывать рейт-лимиты гитхаба и честно останавливать обработку
Мне кажется плохой идеей управлять устареванием кеша путём очистки на уровне кеша потому что мне кажется упереться в лимиты и вывести вчерашний профиль-линк лучше, чем не вывести никакой. Поэтому я за затирание устаревших, если смогли добыть новые данные, но не за удаление.
Чё думаешь?
Нужно нарисёчить насколько большой запрос может съесть апи гитхаба, кстати В целом, по алгоритму согласен Да, про устаревание поинт валидный, но у меня тут вообще PoC 😎 |
Да, но кажется там ограничение типа 100 нод верхнего типа и 500к нод всего или что-то такое: https://developer.github.com/v4/guides/resource-limitations/#node-limit Всё что пишу — чисто чтоб синкнуться чё дальше делать. В этом MR или уже в другом, как думаешь? |
Ещё можно кстати сразу отлавливать рейт-лимиты в ответе как они предлагают и выводить в логи, чтоб не просто "у нас тут ошибка", а "осталось 4к запросов, обнулятся в 12:00" |
Я думаю в этом ПРе можно код причесать и мёржить, а дальше уже отдельно пилить |
No description provided.