#git #tfs #azure-devops
#git #tfs #azure-devops
Вопрос:
В нашей ветке установлены политики develop ветвления, требующие объединения изменений из завершенного запроса на извлечение. Кроме того, наш сценарий сборки автоматически увеличивает номера версий внутри определенных файлов и должен немедленно отправлять обновленные файлы, поэтому в разделе безопасность ветвей мы предоставляем пользователю, который запускает этот сценарий сборки, «Разрешить» «Обходить политики при нажатии». Это работает нормально.
Однако обход политики ветвления для пользователя сборки создает две потенциальные проблемы:
- Если сценарий сборки был изменен (намеренно или нет) для фиксации чего-либо, кроме файлов версий, они будут автоматически отправлены
developбез каких-либо проверок. - Разработчик-мошенник может использовать учетные данные пользователя сборки, чтобы обойти политику запросов на извлечение и напрямую вносить изменения. (Возможно, это можно было бы смягчить, изменив пароль пользователя сборки и не делясь им с разработчиками.)
Есть ли способ разрешить пользователю обходить политику PR только для определенных файлов / папок в push? Если нет, какие другие способы могут быть для достижения этого? (Одна хакерская идея заключалась бы в том, чтобы скрипт сборки автоматически создавал PR, а другой пользователь автоматически анализировал его только для определенных файлов, а затем завершал его.)
В настоящее время мы находимся на TFS on-premise 2015, но скоро перейдем на TFS 2018. В настоящее время мы используем Azure DevOps Server 2019 Update 1, хотя мы можем обновиться, если в более новых версиях есть эта функция (хотя я не думаю, что они есть).
Комментарии:
1. Есть ли конкретная причина, по которой номер версии должен храниться в системе управления версиями? Почему бы не использовать переменную из сборки для установки номера версии, а затем пометить репозиторий идентификатором сборки?
2. например. 1.1.0.$(Build. buildId)
3. @bryanbcook — с другой стороны, кроме «потому что так всегда делалось», я не могу придумать веской причины. Я собираюсь предложить это.
4. да, это то, что мы делаем. Powershell используется для внесения изменений в .csproj и другие файлы в конвейере сборки для увеличения версий. Не выполняя это предложение (что является лучшим способом, если оно работает для вас), вы можете использовать фильтры отрицательного пути, которые позволяют исключать ваши конкретные файлы из политики.
5. @JoshGust Не могли бы вы подробнее рассказать о своей идее фильтрации отрицательных путей? Я не знал, что вы можете это сделать, но моя первоначальная мысль заключается в том, что либо это не поможет, потому что другие политики все равно будут блокировать пользователя от нажатия без PR, или, если это не так, тогда любой сможет нажимать только те файлы без PR, что также не являетсяне желательно. Моя цель — позволить определенным пользователям обходить PR и отправлять только определенный список файлов.