Как я могу издеваться над агентом/сервером CI?

Я уже довольно давно работаю с CircleCI, TravisCI и Azure DevOps.

Хотя прекрасно иметь управляемый сервер, который прекрасно интегрируется со всеми внешними службами, о которых вы только можете подумать (VCS, CD-конвейер, магазины приложений и т. д.), одной из моих самых больших проблем является тестирование CI. При настройке таких систем я трачу большую часть времени на настройку и настройку файлов YAML, сценариев Bash и других частей процесса CI, чтобы они работали быстрее и эффективнее. Однако этот процесс медленный: требуется 1-5 минут даже для получения первого сообщения об ошибке о том, что что-то не так, не говоря уже о иногда 1+ часах для финальных сборок.

Вы можете сделать так много локально — имитировать переменные среды, использовать именно тот контейнер и добавлять учетные данные для соответствующих служб. Но это еще не все. Я предполагаю для этого решение с полным спектром услуг, которое заботится о настройке среды точно так же, как в Azure или Travis, включая получение данных из Git на основе конкретного push-уведомления и тому подобное.

Я мог бы заплатить за это хорошие деньги — это сэкономит мне часы каждую неделю ожидания, пока агенты CI закончат и закончат небольшие операторы ls, pwd и echo, просто чтобы понять, где я, черт возьми, нахожусь.

Есть ли что-то подобное?

Изменить: Это хороший пример "утко- лента", которое могло бы быть очень полезным, но не является полноценным. Я ищу что-то подобное, но более надежное.

Редактировать 2: Это плохой пример решения, которое требует, чтобы я делал самую важную часть — зависимости — вручную.

Редактировать 3: Это имеет много интересных опций, в частности использование Chef и travis-cookbooks или бродяга. Пока это самое перспективное направление, хотя, похоже, только для Трэвиса. Может быть, настроить бродячие ящики для каждого типа агента, который у вас есть?


person Tom Granot    schedule 05.06.2019    source источник
comment
Я не уверен, что понимаю вопрос — зачем вам эмулировать среду CI, которая на самом деле не была CI? Вы хотите определить, пройдет ли конкретная сборка, запустив ее локально, без фактического запуска?   -  person halfer    schedule 08.06.2019
comment
Поскольку большую часть времени я провожу за настройкой и настройкой файлов YAML, bash-скриптов и других частей процесса CI, чтобы они работали быстрее и эффективнее. Подумайте, насколько медленнее программист, если ему требуется 1-5 минут, чтобы даже получить первое сообщение об ошибке, что что-то не так, не говоря уже о том, что иногда 1+ часов для финальных сборок....   -  person Tom Granot    schedule 11.06.2019
comment
Это большой вопрос! Его точно не следует закрывать. Каждый раз, когда я вношу изменения в CI, это случай внесения изменений, запуска CI и ожидания. Лучшая практика говорит, что мы должны вносить небольшие изменения, но процесс здесь заставляет вас хотеть сделать несколько изменений одновременно, чтобы ускорить процесс, а затем, когда что-то сломается, вам придется распаковать все это. Тестирование CI в настоящее время похоже на возвращение на 20 лет назад с точки зрения тестирования.   -  person Matt    schedule 12.06.2019
comment
@halfer - речь идет не о том, будет ли работать простая сборка, а о том, работает ли весь процесс CI. Может быть несколько сборок, несколько наборов тестов, копируемые и публикуемые артефакты, заменяемые токены и т.д. и т.п.   -  person Matt    schedule 12.06.2019
comment
@ t0mgs Итак, вы хотите ускорить CI? Я не совсем понимаю вопрос.   -  person Shayki Abramczyk    schedule 13.06.2019
comment
@ShaykiAbramczyk Я хочу ускорить ТЕСТИРОВАНИЕ моего CI. Если я проверяю что-то на azure-pipelines.yml и делаю небольшие изменения, а не большие вещи, например, проверяю значения переменных среды на определенных этапах сборки, я не хочу раскручивать сервер CI. Я просто хочу посмотреть, что происходит, и перейти к следующей настройке.   -  person Tom Granot    schedule 13.06.2019
comment
@ t0mgs Итак, если у вас есть большой azure-pipelines.yml, и вы хотите выполнить там только 1 или 2 шага (чтобы проверить)?   -  person Shayki Abramczyk    schedule 13.06.2019
comment
@ShaykiAbramczyk Это был бы один пример, который я сейчас использую условия и некоторые хитрости с сообщениями фиксации, чтобы их обойти.   -  person Tom Granot    schedule 13.06.2019
comment
@ t0mgs Я также подумал о пользовательских условиях: вы можете поставить на каждый шаг, кроме настроек, условие для запуска, только если x не равно y, и когда вы хотите проверить, вы устанавливаете x со значением y.   -  person Shayki Abramczyk    schedule 13.06.2019
comment
Я мог, и я делаю. Но я ищу что-то локальное, не занимающее запущенных агентов, не ломающее master, принципиально не затрагивающее никого, кроме меня, и локальное (дважды, просто чтобы удостоверьтесь, что суть понятна:))   -  person Tom Granot    schedule 13.06.2019
comment
Возможно, стоит изучить возможность использования локальных агентов сборки для тестирования, есть образ докера для них   -  person Matt    schedule 13.06.2019
comment
Используя их, но для реальных сборок. Думаю поставить отдельный пул только для пробы. Это не сработает для Трэвиса, Серкла, Кодшипа и других. Это локально для Azure.   -  person Tom Granot    schedule 13.06.2019
comment
@ t0mgs — вы можете следить за этой проблемой github: github.com/microsoft/ azure-pipelines-yaml/issues/32   -  person Matt    schedule 28.06.2019
comment
@Мэтт Подойдет, спасибо!!   -  person Tom Granot    schedule 27.08.2019