История изменений

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.
Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).
Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.
Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Эта штука для разработчиков, а не для пользователей продукта. Ключевой момент тут — автоматизация всего процесса.

Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть туча ограничений, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера, если получится успешно запустить сценарий сборки.

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.
Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).
Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.
Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Эта штука для разработчиков, а не для пользователей продукта.

Ключевой момент тут — автоматизация всего процесса. Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть туча ограничений, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера, если получится успешно запустить сценарий сборки.

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.
Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).
Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.
Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Эта штука для разработчиков, а не для пользователей продукта.

Ключевой момент тут — автоматизация всего процесса.

Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть туча ограничений, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера, если получится успешно запустить сценарий сборки.

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.
Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).
Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.
Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Ключевой момент тут — автоматизация всего процесса.

Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть туча ограничений, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера, если получится успешно запустить сценарий сборки.

Так а зачем это вообще? Там про какие-то папйпы было, проверку статуса задания. Система удалённой сборки что ли?

Так можно сказать только если с натяжкой. Про Continuous Integration (CI) не слышал, что ли? Смысл в том, чтобы упростить цикл сборки/тестирования/деплоя при разработке. В самом простом виде это представляет собой сценарий, который выполняется для каждого коммита, который запушен в удалённый gitlab-репозиторий.

Тем не менее, многие CI-системы (в том числе и Gitlab CI) позволяют сохранять артефакты сборки после успешного прогона сценария (но это нужно уже смотреть в конкретных проектах). Но стоит понять, что редко когда CI используется только ради получения артефактов сборки — чаще акцент идёт на тестирование и деплой.

Вот тебе пара сценариев для примера:

Вы в компании разрабатываете сайт, вас в компании N человек. Для сайта у вас разработана система тестов, есть автоматические проверки кода на соответствие стилю с помощью различных линтеров и т.д.
Так вот, когда твой коллега сделал какую-то фичу, то ты, перед тем как принять эту фичу, хочешь быть уверен, что сайт успешно собирается, проходит все тесты и пр. Ты не приходится самому собирать его ветку вручную, чтобы это проверить (так как чувак это может забыть, а ты не можешь стоять над ним с кнутом), т.к. CI автоматически прогонит сценарий и даст тебе ответ, выполнился ли он успешно или нет (это будет видно как для индивидуального коммита, так и для Pull/Merge Request'а).
Кроме того, когда ты сольёшь эту ветку в dev, то CI автоматически выкладывает сайт на staging-сервер для того, чтобы другие разработчики/тестеры могли руками потрогать новые изменения. После того, как ты убедился, что всё ок, то ты сливаешь это всё ветку master, и изменения выкатываются автоматически уже на продакшн сервер.
Ты разрабатываешь open source тулзу. Ты (или даже какой-то левый васян, которого ты никак не заставишь прогнать тесты) добавляешь новую фичу/фиксишь баг. CI собирает тулзу, прогоняет тесты, ты убеждаешься с некоторой долей уверенности, что новая фича ничего не ломает. Когда эти изменения достигают ветки master, CI может автоматичски собрать пакеты/бинарники и сохранить их как артефакты системы сборки и/или залить их на удалённый сервер.

Ключевой момент тут — автоматизация всего процесса.

Касаемо использования Gitlab CI в качестве локальной системы сборки — это возможно в теории (сам я не пробовал), см. gitlab-runner exec, но у этого способа есть свои ограничения, например, он не поддерживает артефакты сборки. Но я думаю, что в крайнем случае их можно будет вытащить из контейнера.