`docker_manager` должен идти первым

На странице обновления всегда неприятно ждать, пока все плагины проверят наличие новых версий, и в итоге оказывается, что docker_manager нужно обновить первым. Есть ли способ сделать так, чтобы система обновления сначала проверяла, нужно ли обновлять docker_manager, прежде чем искать новые версии? Это сэкономило бы множество HTTP-запросов и время администраторов, которые тратят на обновление больше времени, чем необходимо.

12 лайков

Мне кажется, это отличная идея. Я уверен, что если кто-то захочет над этим поработать, то это будет приветствоваться как pr-welcome :slight_smile:

7 лайков

Отличная идея. Всегда приходится прокручивать вниз, чтобы сначала это проверить.

5 лайков

Я решил попробовать. PR здесь: UX: Always show the docker_manager plugin second in the list by davidtaylorhq · Pull Request #100 · discourse/docker_manager · GitHub

Это всегда будет ставить docker_manager вторым в списке, после самого discourse:

Редактирование: Это уже влитое :tada:

15 лайков

Спасибо, @david! Пропускает ли он проверки для других плагинов, если docker_manager не обновлён?

3 лайка

Нет, они не пропускаются, но это означает, что обновление docker_manager происходит первым. Администратор может сразу же нажать кнопку обновления docker_manager, даже пока другие плагины загружаются.

Как вы думаете, всё ещё полезно видеть, доступны ли обновления для других плагинов, даже если вы не можете установить их сразу?

5 лайков

Обычно, когда появляется новый релиз docker_manager, это связано с тем, что в уведомлениях администратора объявлен новый релиз Discourse, поэтому в 80–90% случаев вы сначала обновляете docker_manager, а затем выполняете полное обновление.

Когда вы хотите проверить отдельный плагин, вам всё равно нужно прокрутить страницу вниз. Я просто думаю об экономии ресурсов. После нескольких лет обновлений на тысячах экземпляров это позволит сэкономить значительное количество ресурсов.

Предположительно, компромиссным решением было бы прекращение запросов проверки при нажатии кнопки обновления docker_manager. Но я считаю, что наиболее разумным подходом будет просто не выполнять проверку, если этот плагин устарел. У меня нет статистики, возможно, она есть у вас.

4 лайка

Мы не используем docker_manager на нашем управляемом хостинге, поэтому, боюсь, статистики нет.

Но «проверка обновлений» — это очень дешевая операция. «Под капотом» docker_manager выполняет git remote update для каждого плагина. Он только подтягивает изменения с момента последней проверки, поэтому объем передаваемых данных должен быть минимальным.

5 лайков

Эта тема была автоматически закрыта через 6 дней. Новые ответы больше не принимаются.