Skip to content

Conversation

@teners
Copy link
Member

@teners teners commented May 17, 2020

No description provided.

@teners teners added the WIP work in progress label May 17, 2020
Copy link
Member

@b0g3r b0g3r left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

На текущем этапе мне в целом всё окей, но давай синхронизируем чё дальше делать.

Как я это представлял:

  1. В ready плагина мы собираем все коммиты репозитория через git log
  2. Генерируем три списка коммитов: новые (которых нет в кеше), просроченные (которые есть в кеше, но старше чем ttl), нормулёк (в кеше и не просроченные)
  3. Обходим новые и добавляем в кэш, а потом просроченные и обновляем их кэш (оба списка обходим пока не упираемся в лимиты, если упёрлись — просто бросаем обход)
  4. Если находим коммит, у которого нет гитхаб-профиля, то кладём в кэш commit.author.name как name, а вместо ссылки профиля ссылку на коммит на гитхабе, например.
  5. В extendPage c помощью git log --follow $page.filePath находим все коммиты связанные с этим файлом и вытаскиваем из кэша данные по контрибьюторам. Генерим список из уникальных контрибьюторов, кладём его в $page

Нужно покопаться и учесть:

  • Нужна функция (profileResolver?), которая получает Array<GitCommit>, RepositoryData и на выходе выдаёт Array<Record<CommitSha, Profile>> — так мы сможем легко переопределить её на гитлаб-гитхаб-гит-етс
  • Нужно посмотреть сколько за раз можно засунуть в апишку гитхаба коммитов и чанковать запрос
  • Нужно научиться обрабатывать рейт-лимиты гитхаба и честно останавливать обработку

Мне кажется плохой идеей управлять устареванием кеша путём очистки на уровне кеша потому что мне кажется упереться в лимиты и вывести вчерашний профиль-линк лучше, чем не вывести никакой. Поэтому я за затирание устаревших, если смогли добыть новые данные, но не за удаление.

Чё думаешь?

@teners teners changed the title ✨ Add GitHub API integration ✨ Add GitHub API integration May 18, 2020
@teners
Copy link
Member Author

teners commented May 18, 2020

Нужно нарисёчить насколько большой запрос может съесть апи гитхаба, кстати
Пока что непонятно, например, мешает ли что-то просроченные коммиты одним графкуэль-запросом вытащить

В целом, по алгоритму согласен

Да, про устаревание поинт валидный, но у меня тут вообще PoC 😎

@b0g3r
Copy link
Member

b0g3r commented May 18, 2020

Да, но кажется там ограничение типа 100 нод верхнего типа и 500к нод всего или что-то такое: https://developer.github.com/v4/guides/resource-limitations/#node-limit

Всё что пишу — чисто чтоб синкнуться чё дальше делать. В этом MR или уже в другом, как думаешь?

@b0g3r
Copy link
Member

b0g3r commented May 18, 2020

Ещё можно кстати сразу отлавливать рейт-лимиты в ответе как они предлагают и выводить в логи, чтоб не просто "у нас тут ошибка", а "осталось 4к запросов, обнулятся в 12:00"

@teners
Copy link
Member Author

teners commented May 18, 2020

Я думаю в этом ПРе можно код причесать и мёржить, а дальше уже отдельно пилить

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WIP work in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants