VA
Я даже POC написал. Получается, что JENKINS тратит кучу ресурсов просто на ответы мне во время поллинга каждые 30 секунд.
Size: a a a
2020 December 19
VA
доступ к дебильному апи облегчается только аггрегатором на входе и кешированием на выходе)
Вот это второй вариант, но возникоает вопрос пересечения доступов и безопасности.
AT
разграничение доступа это уже не к дженкинсу, в общем-то
VA
разграничение доступа это уже не к дженкинсу, в общем-то
Да, это вопрос к этому АПИ. Сейчас бот хранит креденшелы каждого пользователя, который в боте прошёл регистрацию. Но если я между ботом и апи сделаю какую-то прослойку оптимизации, том определенно будет пересечение креденшелов. Я почти сразу отбросил эту идею, так как даже логически не смог эффективно выстроить логику работы
AT
разные юзеры могут отслеживать одинаковые задачи, в этом суть?
AT
в таком случае креденшиалы можно не пересекать, аггрегировать пул задач на входе, и на выходе по каждому юзеру фильтровать
VA
разные юзеры могут отслеживать одинаковые задачи, в этом суть?
Да. Это прям очевидное решение на первый взгляд. У 8 юзеров пересекаются отслеживаемые задачи почти на 100%, значит логично запросить инфу по каждой из задач и отдать юзерам инфу о запуске, если он на это подписан. Но всё равно это сотни запросов при каждой итерации.
AT
ну если сотня задач, то ты не уменьшишь количество запросов.
а там есть данные о прогрессе по задаче? можно интерполировать оставшееся время и таким образом делать запросы реже
а там есть данные о прогрессе по задаче? можно интерполировать оставшееся время и таким образом делать запросы реже
VA
в таком случае креденшиалы можно не пересекать, аггрегировать пул задач на входе, и на выходе по каждому юзеру фильтровать
От чьего имени пуллить все задачи? От имени какого-то конкретного юзера?
С точки зрени безопасности бот сам по себе доступа к Jenkins не имеет. Он берет креденшелы того, кто запрости мониторинг и с ними лезет в Дженкинс.
С точки зрени безопасности бот сам по себе доступа к Jenkins не имеет. Он берет креденшелы того, кто запрости мониторинг и с ними лезет в Дженкинс.
VA
ну если сотня задач, то ты не уменьшишь количество запросов.
а там есть данные о прогрессе по задаче? можно интерполировать оставшееся время и таким образом делать запросы реже
а там есть данные о прогрессе по задаче? можно интерполировать оставшееся время и таким образом делать запросы реже
Десятки задач. Десятки билдов в каждой. Сотни билдов в общем
AT
От чьего имени пуллить все задачи? От имени какого-то конкретного юзера?
С точки зрени безопасности бот сам по себе доступа к Jenkins не имеет. Он берет креденшелы того, кто запрости мониторинг и с ними лезет в Дженкинс.
С точки зрени безопасности бот сам по себе доступа к Jenkins не имеет. Он берет креденшелы того, кто запрости мониторинг и с ними лезет в Дженкинс.
есть список юзеров с его задачами. собираешь задачи в сет, потом аггрегируешь его в {юзер: [задачи]}
AT
т.е. у тебя задачи не будут дублироваться, но каждая будет привязана к подходящим креденшиалам
AT
и если таски пересекаются по юзерам то будет меньше авторизаций как минимум
AT
а сделать вообще отдельного юзера для бота не вариант?
VA
т.е. у тебя задачи не будут дублироваться, но каждая будет привязана к подходящим креденшиалам
Вопрос оптимизации опять же.
2 юзера решили следать за 3 задачами.
например
Вася следит за 1, 2
Петя следит за 2, 3
Есть общий сет задач 1, 2, 3
По логике оптимизации задача 2 должна быть запрошена один раз. Но от чьего имени? Например вдруг у Пети нет доступа к 2, но в общий сет будет записана задача 2 с креденшелами Васи.
2 юзера решили следать за 3 задачами.
например
Вася следит за 1, 2
Петя следит за 2, 3
Есть общий сет задач 1, 2, 3
По логике оптимизации задача 2 должна быть запрошена один раз. Но от чьего имени? Например вдруг у Пети нет доступа к 2, но в общий сет будет записана задача 2 с креденшелами Васи.
VA
а сделать вообще отдельного юзера для бота не вариант?
Не вариант.
AT
Вопрос оптимизации опять же.
2 юзера решили следать за 3 задачами.
например
Вася следит за 1, 2
Петя следит за 2, 3
Есть общий сет задач 1, 2, 3
По логике оптимизации задача 2 должна быть запрошена один раз. Но от чьего имени? Например вдруг у Пети нет доступа к 2, но в общий сет будет записана задача 2 с креденшелами Васи.
2 юзера решили следать за 3 задачами.
например
Вася следит за 1, 2
Петя следит за 2, 3
Есть общий сет задач 1, 2, 3
По логике оптимизации задача 2 должна быть запрошена один раз. Но от чьего имени? Например вдруг у Пети нет доступа к 2, но в общий сет будет записана задача 2 с креденшелами Васи.
неправильно, что он следит за задачей, к которой у него нет доступа
AT
ну и если есть данные о том, у кого к чему есть доступ, то оптимизация решаемая
VA
ну и если есть данные о том, у кого к чему есть доступ, то оптимизация решаемая
Можно запросить задачу и посмотреть ответ. Если дженкинс сказал, что такого нет - то нет доступа. И всё равно даже в такой логике запросов на каждой итерации оч много. Сейчас выворачиваю API Дженкинса наизнанку, пытаясь получить запущенные билды. По идее он должен вернуть только билды тех задач, к которым у юзера есть доступ.
Но пока успеха не добился
Но пока успеха не добился
AT
напоминает апи к powerbi, вот я там настрадался