Я решил опубликовать здесь после публикации на Суперпользователь, так как я хочу получить информацию от разработчиков программного обеспечения, которые, возможно, уже сталкивались с этим сценарием раньше!
Я хотел бы инициировать серию шагов проверки сторона клиента для файлов, открытых в списке изменений, прежде чем разрешить отправку списка изменений.
Например, я хочу гарантировать, что если файл открывается для добавления, редактирования или удаления как часть списка изменений, то конкретный связанный файл будет обрабатываться надлежащим образом на основе матрицы условий для этого соответствующего файла:
Эти шаги проверки должны быть инициированы до того, как отправка будет принята сервером Perforce. Кроме того, проверка должна выполняться на стороне клиента, поскольку я должен иметь возможность согласовать работу в автономном режиме с копиями на дисках клиентов.
Окружающая обстановка:
Следственные авеню уже покрыты
Первоначальный дизайн был строго пользовательский инструмент на стороне клиента, но это не идеально, поскольку это будет изменение потока, с которым пользователи знакомы, и мне также придется реализовать собственный графический интерфейс.
Среди других подходов я рассматривал создание триггеров в 2017.2; однако, даже если бы я использовал триггер изменить содержание со всеми файлами списка изменений, доступными на сервере, я не смог бы должным образом выполнить шаги проверки и исправления.
Другой возможностью было бы использование триггер отправки изменений и использование запускать переменные скрипта в 2017.2 для получения IP-адреса клиента, имени хоста, текущего рабочего каталога клиента и т. д., чтобы вы могли запустить сценарий на сервере, чтобы попытаться удаленно подключиться к компьютеру клиента. Однако для запуска любого сценария на клиентском компьютере и, в частности, для работы в его локальной рабочей области потребуются учетные данные, которые, скорее всего, не будут доступны.
Я хотел бы использовать триггер отправки изменений на сервере Perforce, чтобы инициировать сценарий/связанный исполняемый файл на клиентском компьютере для выполнения операций p4 в их рабочей области для завершения шагов проверки. Однако ссылки, которые я нашел (хотя и много лет назад), указывают на то, что это невозможно:
Спасибо за прочтение и заранее за помощь!
Привет, @DerekPollard! Не могли бы вы дать мне несколько предложений относительно того, как я могу уточнить свой вопрос? Я мог бы попытаться создать TL; DR, который мне нужно знать, смог ли кто-то это сделать, или это ограничение механизма запуска Perforce :)
running any script on the client's computer and in particular operating on their local workspace would require credentials that most likely will not be made available.
В этом суть — серверу Perforce не разрешено отправлять клиенту произвольный код для выполнения. Если вам нужна такая функциональность, вам придется пробить собственную дыру в безопасности клиента (а затем придумать свой собственный способ убедиться, что он не используется не по назначению), и похоже, что вы уже прошли этот путь. и решил, что оно того не стоит.
Initial design was a strictly client-side custom tool, but this is not ideal since this would be a change of the flow that users are familiar with, and I would also have to implement a custom GUI.
Я бы порекомендовал начать с этого подхода, а затем искать способы уменьшить трение. Например, вы можете использовать триггер отправки изменений, чтобы определить, пропустил ли пользователь настраиваемый рабочий процесс (возможно, за счет того, что пользовательский инструмент поместил токен в описание изменения для проверки триггера), а затем дать им сообщение об ошибке, которое помещает их обратно в нужное русло, например «Пожалуйста, запустите «Инструменты» > «Проверка изменений» или обратитесь за помощью по адресу [email protected]».
Ха-ха, черт возьми, это был первоначальный план: чтобы отправить отправку через пользовательский инструмент, у нас был бы триггер на сервере Perforce для проверки. Значит, нет возможности запустить код, который уже существует на клиентской машине, с помощью триггера отправки изменений? т. е. изменение-отправка вызывает запуск сценария на сервере, который затем использует соединение, которое принудительно уже открыто для клиента, для запуска сценария? Большое спасибо за руководство, Сэм!!
Я имею в виду, есть всегда способ. Самый простой способ — настроить микросервис на каждом клиенте и убедиться, что триггер имеет к нему доступ. (Это метод "пробить свою собственную дыру в безопасности клиента" - каждый раз, когда вы открываете какой-либо новый метод удаленного выполнения, вы хотите тщательно подумать о том, как его можно использовать не по назначению...)
К сожалению, это, вероятно, не по теме, так как это слишком широко