Шаг прогонов под профлист: Обрешетка под профнастил

Шаг прогонов под профлист: Обрешетка под профнастил – шаг прогонов.

alexxlab | 11.10.1986 | 0 | Разное

Содержание

Обрешетка под профнастил: шаг, расчет, расстояние, монтаж

Профилированные металлические листы – это популярный материал для финишного покрытия крыш строений различного назначения. Производятся они с профилем в форме трапециевидной волны. Высоты гребня настила, применяемого для кровли, не должно быть ниже 3,5 см и данный параметр четко регламентирован ГОСТами и СНиПами. Достоинств у материала довольно много, например, можно отметить, такие качества, как легкость, высокая прочность и долговечность. Листы имеют двойное защитное покрытие, то есть оцинкованное и полимерное, что позволяет защитить поверхность кровли от негативных факторов внешней среды. Также можно отметить и тот факт, что изделия не выгорает на солнце, а значит, свой внешний вид крыша будет сохранять на протяжении всего срока эксплуатации.

Еще один важный момент для многих пользователей – это экономическая выгода подобного приобретения. Ведь стоимость материала ниже, как аналогичной продукции, так и многих других вариантов кровельных покрытий. Кроме того, произвести самостоятельный монтаж не составит труда даже для пользователей, впервые сталкивающихся с этим изделием. Разумеется, прежде чем приступить к установке металлических листов, стоит внимательно изучить все особенности процедуры, уделив особое внимание такому вопросу, как обрешетка под профнастил. Так как во многом от данного элемента будет зависеть долголетие и прочность крыши строения. Именно поэтому стоит подробно рассмотреть этот элемент кровельного пирога, но прежде всего, стоит уделить внимание особенностям профилированного настила.

Особенности профнастила

Профилированное металлическое кровельное покрытие выпускается с различными вариантами профиля. Кроме того, изделие может отличаться не только геометрией волны, то есть формой и высотой гофры, расстоянием между волнами, но и такими параметрами, как монтажная ширина, материал изготовления, толщина листа, качество антикоррозийного покрытия и наличие различных декоративных полимерных слоев. Чтобы точно знать, какими свойствами обладает приобретаемый профнастил, достаточно взглянуть на его маркировку. Пользователям следует знать, что изделие выпускается в трех основных модификациях:

Несущий (маркируется литерой Н).
Стеновой (С).
Комбинированный или универсальный (НС).

Материал может отличаться своим предназначением, например, изделие может использоваться:

для монтажа кровельной системы;
для устройства межэтажных перекрытий;
для отделки фасадов;
для изготовления стеновых перегородок;
для установки в качестве ограждающих конструкций и так далее.

Потребители, планирующие сделать кровлю самостоятельно, должны разбираться в назначении выбираемой продукции. Маркируется материал буквенно-цифровым обозначением. Цифры в маркировке означают высоту профиля, толщину листа, монтажную ширину и длину материала в мм.

Расчет и монтаж обрешетки под профнастил

Обрешетка может выполняться из дерева, железобетонных плит либо из металла. При этом металлическая обрешетка под профнастил применяется в случае использования листов толщиной более 0,7 мм на кровлях с минимальным уклоном скатов. Прежде чем приступить к составлению расчетов, стоит определиться с маркой используемого материала, а также распланировать уклон кровли для профнастила. Кроме того, во внимание необходимо брать ветровые и снеговые нагрузки, которые наблюдаются в конкретном регионе. Посмотреть коэффициент можно в специальных таблицах, которые имеются в свободном доступе на интернет-ресурсах. Правило будет действовать следующее: чем сильнее, чаще ветер и больше осадков, тем меньше шаг обрешетки под профнастил.

Каждый пользователь, планирующий самостоятельный монтаж профилированных листов, должен понимать, что обрешетка – это лишь верхний элемент кровельного пирога, к которому и производится непосредственное крепление декоративно-защитного покрытия крыши. Для фиксации самой обрешетки необходимо произвести монтаж конробрешетки, которая выполняется из доски толщиной 3-4 см. Последовательность монтажа следующая:

на стропильную систему стелется пароизоляционный материал;
вдоль стропильных ног набивается брус контробрешетки;
поперек контробрешетки монтируется обрешетка из бруса с квадратным сечением в 5 на 5 см или доски с толщиной от 30 на 100 с выбранным заранее шагом.

Чтобы основание для профилированного настила получилось максимально прочным и долговечным, стоит внимательно изучить технические требования из ГОСТов предъявляемые к обрешетке, а также другие регламентирующие документы. Важное правило, которого следует придерживаться в обязательном порядке – это применение антисептической, антипиренной и гидрофобизирующей обработок. Стоит иметь в виду, что обрешетка под профлист в местах соединения стропильных ног, в районе конька, в местах прохода вентиляционных труб, дымохода и мансардных окон должна быть двойной, именно такой подход обеспечит дополнительную герметичность кровли. Для расчета требуемого пиломатериала следует брать во внимание такие размеры, как ширина и длина скатов, а также планируемый шаг монтажа досок. Кроме того, к конечному результату стоит добавить 10% запас, который обязательно образуется при подрезе материала.

Чаще всего, выполняется обрешетка под профнастил своими руками из деревянных брусьев, а крепление производится при помощи гвоздей. При этом длина крепежных элементов должна быть как минимум в 3 раза больше толщины используемых досок обрешетки. Профлист фиксируется на досках обрешетки при помощи специальных саморезов для профнастила, снабженных резиновым уплотнителем под шляпкой. Крепление производится в углубление профиля на скатах кровли и в вершину волны на коньковом брусе. Монтаж начинается от торца крыши, каждый последующий лист укладывается с поперечным нахлестом не менее 5 см, а продольным от 20 см, читайте также: как покрыть крышу профнастилом своими руками.

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

на стену из металла, толщина доски, проектирование

Профилированный лист – популярный кровельный материал. Работать с ним просто и удобно. Из легких и прочных панелей делают односкатные, двухскатные и вальмовые крыши, заборы, используют их как обшивку для стен. Чтобы кровля была надежной и долговечной, нужно правильно подобрать шаг прогонов под профлист. Здесь нельзя экономить, но и слишком часто ставить рейки не стоит, чтобы не утяжелять всю стропильную систему и дом в целом.

Содержание

Расчет и проектирование обрешетки
Материал для обрешетки
Разреженная обрешетка для крутых крыш
На что ориентироваться при проектировании обрешетки

Расчет и проектирование обрешетки

Шаг обрешетки зависит от уклона крыши и толщины профлиста

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

Расстояние между брусьями обрешетки под профнастил определяет способность кровли противостоять ветровой и снеговой нагрузке, оставаться герметичной при сильном ветре во время дождя.

При проведении расчетов нужно принимать во внимание такие факторы:

Климатические условия. Сила и направление господствующих ветров, уровень осадков в холодное время года.
Толщина металла, из которых сделаны панели. Чем он тоньше, тем меньше интервал между рейками.
Высота профиля. Изделия с высокими гребнями намного лучше противостоят механическим нагрузкам.

В соответствии с ГОСТ шаг обрешетки определяется путем сопоставления крутизны ската и высоты гофры.

При строительстве используются такие модели профлиста:

С. Отделочный материал, не предназначенный для выполнения защитных функций. Толщина стали составляет 0,4-0,6 мм при высоте волны до 10 мм.
НС. Более прочное покрытие толщиной 0,6-0,85 мм и высотой гребня до 44 мм. Применяются как для облицовки зданий, так и в изготовлении крыш различной сложности и размера.
Н. Самые крепкие и надежные панели. Используются для создания кровельного настила, заборов и опалубки под плиты перекрытия. Высота волны до 140 мм при толщине 0,9-1,2 мм.

К каждому виду товара прилагается инструкция с описанием его технических характеристик и условий применения.

Универсальный

30.56%

Кровельный

55.56%

Посоветовался бы с мастером

13.89%

Проголосовало: 36

Материал для обрешетки

Как правило, обрешетку делают из бруса

В большинстве случаев в жилищном строительстве стропильная система изготавливается из бруса и реек. Обрешетка является самым верхним слоем, который принимает на себя вес настила. Она должна быть достаточно прочной, чтобы сохранять форму при внешних механических нагрузках, и долговечной, чтобы без замены отслужить на протяжении всего срока службы облицовки.

В соответствии с положениями сборника ГЭСН-12 доска для обрешетки крыши под профнастил подбирается под параметры настила и расчетный вес максимального количества снега, который теоретически может скопиться на крыше.

Толщина доски на обрешетку крыши под профнастил выбирается и под конкретные строения:

небольшая беседка — 20 мм;
навес для машины — 30 мм;
гараж, сарай, мастерская — 40 мм;
жилой дом, дача, коттедж — 50 мм.

Ширина рейки варьируется в пределах 50-100 мм в прямой зависимости от размеров крыши и ее пологости. К сорту древесины особых требований не предъявляется, так как она защищена от влажности, вероятность гниения практически исключена.

Другим вариантом выбора направляющих для изготовления обрешетки являются П-образные оцинкованные стальные профили. Применяются при строительстве гипсокартонных перегородок и вентилируемого фасада. Металл лучше переносит перепады температуры, а при качественной обработке — и влажности. Работать с профилями немного сложнее, но они меньше весят и теоретически имеют более долгий срок службы.

Как альтернативу можно рассматривать трубы прямоугольного сечения. Изделия очень прочные и рассчитаны минимум на 50 лет эксплуатации. Соединение может проводиться на саморезы и заклепки. Минус в том, что и обрешетка получится тяжелая, смета окажется заоблачной.

Разреженная обрешетка для крутых крыш

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

В зависимости от крутизны ската принимаются такие значения расстояний между рейками обрешетки:

минимальный угол — 25-30 см;
средний угол — 35-60 см;
крутой угол — 65-100 см.

При использовании профнастила марки «Н» и бруса 50х50 мм допускается увеличивать шаг между опорами до 40 см. Здесь нужно обращать внимание на качество оборудования свесов. Их конструкция должна быть такой, чтобы было полностью исключено проникновение ветра под листы и поднятие всего настила.

Валера

Голос строительного гуру

Задать вопрос

Брус нужно крепить снизу вверх, используя уже зафиксированные рейки в качестве опоры. Чтобы исключить срыв конструкции сильным порывом ветра, ближе к карнизу нужно ставить рейки чаще, используя не гвозди, а длинные саморезы, вкручиваемые непосредственно в стропильные ноги. Толщину реек следует увеличить, чтобы компенсировать отрывное усилие ураганных порывов.

На что ориентироваться при проектировании обрешетки

Процессу строительства предшествует планирование, проектирование, выбор и закупка материалов. На данном этапе мастерам приходится выбирать прочность настила и обрешетки. Здесь действует пропорциональная зависимость — чем толще лист, тем больше расстояние между досками и наоборот.

Учитывая, что срок службы обоих материалов практически одинаков и не зависит от толщины, следует рассмотреть вопрос с точки зрения стоимости. Тут могут быть и свои нюансы, присущие той или иной местности. Где-то древесина дороже, где-то дешевле, а металл стоит примерно одинаково везде.

Если есть возможность по доступной цене приобрести доски, можно сделать сплошную обрешетку и уложить на нее стеновой профнастил толщиной 0,45-0,5 мм. Под сплошной конструкцией подразумевается расположение реек на расстоянии 1-5 см. Ставить их впритык не нужно с точки зрения несущей способности и с учетом расширения при влажной погоде.

Валера

Голос строительного гуру

Задать вопрос

Если делается плоская крыша, нужно учитывать, что горизонталь не устанавливается. Минимальный уклон для стока воды должен составлять 5 градусов. Даже для несущих марок листов в таких сооружениях нужно делать учащенную обрешетку. Ни панели, ни каркас не в состоянии противостоять давлению метрового слоя мокрого снега. Поэтому для ровных кровель берется интервал в пределах 30-50 см. Для плит марки «СН» — 25-40 см, а марки «С» в таких конструкциях не используются.

Шаг обрешетки под профнастил

Автор Кровельщик На чтение 9 мин Просмотров 2.3к. Обновлено 05.08.2017

Содержание

Обрешётка под профнастил для крыши
Применение профилированного листа
Способы крепления обрешётки под профилированный настил
Выбор материалов для настила профилированного листа
Виды каркаса для обрешётки и особенности его конструкции
Этапы монтажа обрешётки под профилированный настил
Крепление профилированного листа к обрешётке
Виды профилированного настила

Обрешётка под профнастил для крыши

Очень удобным способом покрытия крыши является профилированный настил. Использовать этот универсальный строительный материал можно при сооружении жилых домов и дач, хозяйственных построек и гаражей, навесов и беседок. Он станет надёжной защитой для дома или другого сооружения. Но чтобы крыша из профнастила служила дольше, нужно подобрать обрешётку, а также её шаг.

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

Применение профилированного листа

Профилированный лист нашёл своё применение в сооружении:

«Сэндвич-панелей»;
Металлических заборов;
Отделки стен;
Кровля крыш;
Сооружение опалубки.

Часто можно заметить, что заборы вокруг строек возводят из профилированных листов. Объяснить такое решение можно тем, что профнастил

лёгок в установке, нетребователен в уходе, а также долговечен.

Владельцы частных домов довольно часто огораживают территорию своего участка металлическими листами с рельефом.

На это влияет цена и надёжность при использовании забора как постоянной ограды.

Оцинкованные или с полимерным покрытием листы могут быть использованы при перекрытии крыш и их ремонта.

Способы крепления обрешётки под профилированный настил

Варианты крыши: односкатная и двускатная.

Основной составляющей частью обрешётки являются брусья, что укладываются под прямым углом к стропам.
Выбрав нужный шаг, брусья крепят болтами, скобами либо, наиболее часто, гвоздями. Правильно рассчитанная обрешётка продержит вашу кровлю очень долго.
Вдоль карниза должна
быть расположена доска, которая толще основных обрешеточных брусьев.
Дополнительного укрепления требуют и особенности крыши, например, дымоход, окно, пожарный люд и другое. В этом случае стоит укрепить периметр выходов дополнительными досками.
Крепление профилированного настила происходит только после того, как было застелено изоляционное полотно и установлена вентиляционная система.
Толщину стоит рассчитать, беря во внимание высоту профнастила и длину креплений снаружи, что держат профиль.
Рекомендовано выбирать расстояние между шагами не более тридцати сантиметров. А с уменьшением угла наклона, то есть, чем менее крутая крыша, тем шаг обрешётки должен уменьшаться.
Берётся во внимание и то, насколько прочен и толст материал, в какой мере лёгок профнастил и при каких условиях погоды он должен держаться.

Стоит установить на торцах крыши ветровые доски. Они должны возвышаться над каркасом настолько, чтобы закрывать профнастил.
Длина шага во многом зависит от высоты крыши, града, снега и прочих осадков, что делают дополнительную нагрузку на крышу.
Чем длиннее была выбрана высота профиля, тем более высокая нагрузка на крышу может быть допущена.
Если крыша имеет скат не более пятнадцати градусов, то используют тип профнастила С20 (использование сплошной обрешётки и укладка профилированных листов производится внахлёст, двумя волнами).
При использовании листов типа С35, шаг обрешётки увеличивают до тридцати сантиметров, и укладка листов производится одной волной. Если при этом типе монтажа использовать шаг в 55 – 65 сантиметров, то надо готовиться к уменьшению критической нагрузки.

Тип профнастила С44 кладут при шаге обрешётки в шестьдесят пять сантиметров. При данном шаге можно использовать и высшие категории профилированного настила.
Использование антисептиков и других веществ, что могут защитить дерево от вредителей и неблагоприятных условий желательно, но необязательно. Они помогут вашей крыше простоять очень долго и не требовать дополнительного ремонта.
Для наиболее удобного монтажа следует использовать специализированные саморезы. Они имеют сверло на конце и обрезиненную основу под шляпкой. Выпускают данные саморезы всех цветов и окрасок, для того, чтобы подходить под ваш тип крыши.
Крепят профилированные листы на саморезы, гвозди или V-образные крепления. Использование гвоздей оправдано при облицовке стен и сооружении щитов защиты.
Укладка профилированного листа производится от нижних рядов к верхним.
Крепят листы к деревянной основе в углублениях между волнами.
Края нижнего ряда профилированного листа должны выступать, создавая карниз, на 15 – 20 сантиметров от стен здания. Это убережёт последние от повреждений и порчи облицовки.
Устройство обрешетки под профнастил требует использования деревянных брусьев или досок, уложенных вплотную либо вразрядку перпендикулярно стропилам.

Совет. Обработать края брусьев от заноз и сколов легче на земле, ещё до сбора конструкции. Также пропитка антисептиком легче осуществляется по разобранному каркасу, чем по смонтированному.

Выбор материалов для настила профилированного листа

В промышленных и высотных зданиях используются металлические брусья и перекрытия.

Для частных домов стоит выбирать пиломатериалы.

Размеры среза деревянного бруса не должн быть меньше 50 на 50 миллиметров.
Стоит подсчитать количество материалов в местах выхода дымохода, окон или пожарных люков. Там расход дерева увеличивается в два раза. На краях крыши используется не одна, а сразу две доски, что придаёт покрытию дополнительной прочности.
Кроме брусьев можно пользоваться толстой доской с толщиной не менее пятидесяти миллиметров.
Материал должен быть сухой, без признаков деформации, а также не иметь дефектов.
Деревья можно выбирать такие как ель, сосна, бук, ольха.
Можно приобрести уже готовые материалы с пропиткой антисептиком и противопожарной смесью. Однако, уже готовые непропитанные брусья можно обработать покупными составами, которые обеспечат полную защиту за одну обработку.

Виды каркаса для обрешётки и особенности его конструкции

При выборе конструкции обрешётки важно учитывать угол наклона ската крыши, высоту гофры профилированных листов, и количество скатов (односкатная или двускатная крыша).

В следующей классификации будут приведены типы обрешётки от самого малого шага до самого большого шага между брусьями.

Сплошная обшивка из фанеры или OSB. При этом крышу полностью устилают деревянными листами, что будет служить основой для настила. Такой тип используется для настила мягких кровельных материалов типа рубероида.
Сплошная контробрешётка. Если обрешётка с большим шагом, то рейки, что идут по диагонали крыши, создают почти сплошной настил. Подходит для кровли многими кровельными материалами.

Сплошная обрешётка под полужесткие крупные настилы. Здесь доски настилают параллельно друг другу и вдоль крыши. Подходит для ровных листов металла или не гофрированного профнастила.
Разреженная обрешётка под малоразмерные, жёсткие кровельные материалы. Шаг обрешётки немного меньше листа материала. Подходит для малогабаритных гофрированных профнастилов.
Разреженная обрешётка под крупноразмерные жёсткие кровельные материалы. Шаг этого каркаса позволяет класть на два пролёта один лист материала.

[youtube id=»VO_XRw_Fb1k» align=»center» mode=»normal»]

Этапы монтажа обрешётки под профилированный настил

Расчёт затрат материала. Создав чертёж на бумаге, обмеряв метраж с учётом коньков, выступов и прочих особенностей крыши, можно рассчитать количество пиломатериалов, что уйдут на устройство обрешётки.

Подготовительный этап, выбор и закупка дерева.Убрав из предлагаемого ассортимента дефектные доски и брусья, стоит обратить внимание на ценовую категорию и качество. Оптимальными в этом плане станут хвойные породы (ель, сосна, кедр).
Обработка материалов противокоррозионными и противопожарными средствами. Так как обрешётка часто используется в тёплых помещениях, стоит задуматься о защите дерева от гноения и грибка. А ещё противопожарная безопасность требует обработки дерева противопожарным составом. Можно заказать как отдельно жидкость для обработки, так и уже заранее пропитанные элементы каркаса.
Продаются составы, что комбинируют в себе как гидрозащитные свойства, так противопожарные. Такой вариант сэкономит вам не только силы, но и деньги. Можно обработать обрешётку уже после установки или ещё до монтажа. В последнем случае намного легче проводить работы.

Монтаж и устройство каркаса. Перед монтажом каркаса кладут гидроизоляционный слой:

1. нанесите разметку под предполагаемое местоположение брусьев, и нижних коньков;
2. при крепеже брусков к деревянной основе, нужно пользоваться строительными гвоздями;
3. при крепеже брусков на бетонную основу или основу из цемента, используйте дюбеля;
4. для крепежа металлических составляющих, стоит использовать саморезы.

Все последующие элементы монтируйте снизу вверх. А для соблюдения параллельности досок, натягивайте шнур по разметке с разных сторон крыши.

Шаг обрешетки под профнастил С-8, П-18, МП-20, п-20, С-20, НС-35, Н-60, Н-75, С-44.

Крепление профилированного листа к обрешётке

Укладка профилированного настила довольно простой процесс. Укладывают его параллельно ходу карниза. Настилают только вдоль крыши и снизу вверх.

Для начала надо гидроизолировать и утеплить кровлю. Этим целям хорошо послужат ПВХ-мембраны, а также как утеплители – пенопласт и стекловата.
Укладка листов происходит внахлёст, что напрямую зависит от угла наклона крыши.
Все зазоры, что образовались при монтаже, следует хорошо пропитать битумной мастикой.
К дереву профилированные листы крепятся саморезами со сверлом на конце, под шляпками имеется обрезиненный участок. Сами шляпки окрашиваются в различные цвета, для соответствия окраске настила крыши.
Чтобы слой гидроизоляции работал исправно, стоит предусмотреть зазор между этим слоем и настилом профилированных листов. Он должен составлять 20 – 40 миллиметров. Достичь этого можно наложением реек из соответствующей толщиной прямо на слой изоляции.

Виды профилированного настила

Маркировки по ГОСТ 24045-94:

Кровельный. Высота волны будет разная, от 35 до 44 миллиметров. На этой разновидности профнастила будет нанесена маркировка «CH». Кровельный настил подойдёт для сооружения новой крыши и капитального ремонта старой. Поскольку он очень прочный, то выдерживает большие снежные нагрузки даже на горизонтальной крыше.
Стеновой. Волна будет высотой 35 – 44 миллиметра. Используется для обшивки стен, установки заборов и постройки малых конструкций. Хотя и допускается настил такого материала на крышу, но её уклон должен быть большим и обрешётка иметь сплошной вариант перекрытия. Но не стоит экономить, лучше выбрать тип накрытия «CH».

Разновидности профнастилов:

Комбинированный профнастил. Его используют как один из составляющих элементов для различных конструкций. Как несущий материал, его тоже можно использовать.
Профнастил оцинкованный. Не имея полимерного слоя, его нельзя использовать для сложных условий. Однако из-за прочности и небольшой цены, можно использовать как накрытие на крышу.
Крашеный профнастил. Это не только повышенная эстетичность, но и дополнительная защита от внешних воздействий. Можно использовать в любом типе сооружений, от отделки стен до покрытия крыши.
Профнастил из алюминия. Отличается повышенной устойчивостью к разрушительным факторам. Это было достигнуто покрытием оксидной плёнкой, она защищает крышу от повышенной влажности.
Опорный (несущий) профнастил. Из-за особой конструкции, эти виды настила выдерживают наибольшую нагрузку.
Кровельный профнастил. Можно использовать как накрытие, так и для облицовочных работ. Удобен в настиле крыши, так как его можно класть по методу укладки шифера.
Облицовочный (стеновой) профнастил. Используется как защита для стен и прочих конструкций, где используется обрешётка.

Выбирая тип обрешётки, стоит учесть не только желаемую форму крыши, но и тип накрытия, условия при которых она будет использоваться, а также вид материала, что будет ложиться на каркас. Рекомендуется выполнять расчет обрешетки под профнастил, в соответствии с параметрами, указанными производителем (они не выходят за пределы требований СНиП).

как правильно сделать, какое расстояние между обрешеткой под профлист, доска или металлическая обрешетка

Содержание:

Преимущества материала
Виды материалов для обрешетки под профнастил
Расчет расстояния между обрешеткой под профлист
Особенности монтажа на крыше
Как правильно сделать обрешетку

Выбирая кровельные материалы, большинство потребителей отдает предпочтение профлисту. С помощью этого практичного и функционального материала можно обновить крышу за небольшой промежуток времени. Благодаря высокой механической прочности, а также устойчивости к коррозии профлисты занимают лидирующие позиции в строительстве малоэтажных жилых и производственных зданий.

Преимущества материала

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

Виды материалов для обрешетки под профнастил

Под обрешеткой принято понимать основание под кровельный материал, выполненное из металлического профиля или деревянных реек, укладка которых выполнена в перпендикулярном направлении относительно стропил.

Обрешетка крыши под профнастил принимает на себя нагрузку от кровельного покрытия, распределяя ее между стропилами, что помогает избежать преждевременной деформации крыши. Монтаж профлистов может выполняться на сплошную обрешетку или выполненную с определенным шагом в зависимости от технических характеристик материала.

В качестве материала для изготовления обрешетки может использоваться следующее:

Древесина. Это самый распространенный вариант для изготовления обрешетки под профнастил. Легкость и прочность натурального дерева способствуют созданию прочных и надежных конструкций. Такое основание изготовляют из досок с обрезанной или необрезанной кромкой. Доска на обрешетку под профнастил может иметь ширину 15 см, а толщину 4-5 см. Недостатком деревянных изделий считается легкая возгораемость и плохая устойчивость к воздействию воды, что является причиной быстрой потери прочности. Решить проблему помогает обработка материала гидроизоляционными средствами и антипиренами.
Металл. При строительстве производственных помещений чаще всего используют металлический профиль. Такие элементы не имеют ограничений по длине и отличаются повышенной прочностью при незначительном весе. Металлическая обрешетка под профнастил может устанавливаться с шагом до 1,5 метров. Несмотря на то, что воздействие воды может вызвать появление коррозии на металлических изделиях, эксплуатационный период у них все-таки больше по сравнению с деревянными конструкциями.

Расчет расстояния между обрешеткой под профлист

Прочность профлиста и его устойчивость к механическим повреждениям обеспечивается за счет дополнительных вертикальных ребер жесткости. Несущая способность материала возрастает с увеличением высоты волны изделия. Обрешетка под профлист монтируется в зависимости от вида и массы кровельного материала. Также необходимо учитывать площадь ската и угол его наклона. Промежуток обрешетки определяется строительными нормами.

Выполнение расчетов проводится в зависимости от уклона:

На крыше с уклоном менее 15 градусов под профнастил рекомендуется наколачивать сплошную конструкцию. Кровельные материалы несущего типа могут укладываться на решетку в шагом до 40 см.
При наклоне ската от 15 до 30 градусов расстояние между обрешеткой под профнастил может составлять от 30 до 65 см. Такие параметры используются при монтаже обрешетки на большинстве крыш, так как являются наиболее подходящими для профнастила.
Крыша, имеющая наклон в 30 градусов, может иметь обрешетку с шагом до 1 метра.

Профнастил несущего типа имеет высоту волны более 8 см, поэтому характеризуется повышенной жесткостью. Следовательно, укладку можно выполнять на обрешетку, у которой расстояние обрешетки для профнастила составляет 3-4 метра, а наклон крыши превышает 8 градусов.

Особенности монтажа на крыше

Чтобы разобраться с вопросом, как правильно сделать обрешетку крыши под профнастил, нужно изучить характеристики кровельного материала.

Универсальный и несущий профнастил имеет высоту волны более 3,5 см, для его изготовления используют оцинкованную сталь с толщиной листа 0,6-0,7 мм. Настилать такой материал можно на обрешетку с шагом между элементами до 1,5 метров. Несущие способности такой крыши составляют до 600 кг, что во многом упрощает ее обслуживание.

Профнастил стеновых марок имеет высоту волны не более 2,1 см, что делает материал менее прочным. Следовательно, его укладка должна выполняться на сплошную обрешетку. Это предотвратит деформацию кровельного материала под воздействием снежного покрова.

Как правильно сделать обрешетку

При монтаже конструкции, включая обрешетку на гараж под профнастил, следует придерживаться следующих рекомендаций:

Крепить элементы обрешетки нужно на рейки контробрешетки. Их устанавливают параллельно стропильным ногам для фиксации гидроизоляционного материала.
Деревянные элементы обрешетки крепятся гвоздями, а металлический профиль – саморезами.
Выполнять монтажные работы нужно снизу вверх. Крепление первой основной доски, которая представляет собой более толстый брусок, проводится вдоль карниза.
При укладке элементов обрешетки необходимо контролировать горизонтальность.
Каждую рейку обрешетки следует крепить двумя крепежными элементами. Это предотвратит выворачивание бруска при интенсивной нагрузке.
При недостаточной длине элементов обрешетки можно выполнить их соединение. Однако не рекомендуется соединять на одной стропильной ноге элементы соседних рядов.

Обрешетка крыши под профнастил

Обрешетка крыши частного жилого дома

Как и любая другая работа, обрешетка крыши под профнастил требует подготовки: необходимо закупить материал (доски, крепеж), подобрать инструмент, изготовить или приобрести лестницы.

Доски для обрешетки должны быть сухими. Иначе после монтажа их поведет, вследствие чего герметизация стыков может быть нарушена. Толщина доски варьируется от 20 до 50 мм, можно применять брус с квадратным сечением на 50, 60, 75 мм.

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

Работу лучше выполнять с помощником, приготовив: молоток, рулетку, ножовку, стремянку, гвозди на 100 или 150 мм. Монтаж обрешетки крыши лучше выполнять в сухую погоду, предварительно подняв наверх необходимый материал и инструменты.

Расстояние между досками обрешетки крыши под профнастил может быть разным. В одних случаях ее делают сплошной, оставляя между досками зазоры по 10 мм на случай разбухания древесины. В других делают обычный шаг 200-400 мм или разреженный – 500-700 мм.

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

Закончив разметку, можно начинать крепить обрешетку. Если доски не напилены в размер, а это бывает в случае, когда их предстоит сращивать из-за недостаточной длины, с левого торца лучше натянуть нитку и выставлять доски по ней. Тогда правый торец, после окончания работу по натянутой нитке будет отпилить легче. Для левшей все делается зеркально.

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

После окончания работ внимательно осмотрите обрешетку. Она должна быть в одной плоскости по всему периметру ската. Выпуклости, вогнутости не допускаются. Это отрицательно скажется на монтаже финишного покрытия. Теперь вы знаете, как сделать обрешетку под профнастил на крышу. Надеемся, трудностей при работе у вас не возникнет.

Обрешетка односкатной крыши под профнастил

Кровли такого типа обустраиваются на небольших строениях: флигелях, дровяных сараях, гаражах. Угол наклона односкатной крыши, как правило, небольшой. Нужно иметь в виду, что минимальный допустимый угол наклона для скатной кровли составляет 12 градусов. В случае меньшего уклона крыша уже становится больше похожа на плоскую. Вода при косом дожде и таянии снега на кровле может затекать через стыки кровельных материалов, а это недопустимо.

Ветровая нагрузка на односкатную кровлю минимальная вследствие ее малой парусности. Зато у такого типа кровли весьма большая снеговая нагрузка, о чем нужно помнить уже на стадии проектирования такой кровли и проектировать ее с хорошим запасом прочности. Скатная кровля должна быть жесткой, не прогибаться под массой снега, имеющего во время оттепелей большой вес. Для этого либо профилированные листы берутся толще и с более высокой «волной», либо шаг обрешетки делается чаще.

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

Как правильно выбрать тип обрешетки крыши

Разновидность обрешётки зависит от двух основных параметров: угла наклона ската и марки профлиста. Если угол наклона, к примеру, составляет 14 градусов, а профлист марки С10 – понадобится сплошная обрешётка. При том же угле наклона и листе С21 надо делать обычную обрешетку с шагом 300 миллиметров, для профнастила из листа С44 монтируют разреженную обрешетку с шагом 600 миллиметров.

При увеличенных нагрузках на кровлю, для обеспечения максимальной прочности, используют обрешетку в два слоя. Нижнюю делают облегченной, с шагом от 500 до 700 миллиметров, верхнюю – с обычным шагом или сплошную. Такой вариант применяется также в случае укладки утеплителя большой толщины.

Метизы при монтаже обрешетки подбираются в 2 раза больше ее толщины. К примеру, если используется брусок 70х70 миллиметров, то гвозди нужно брать длиной не менее 150 мм.

Узнать подробнее о профнастиле!

Предыдущая Следующая

Угол наклона крыши из профнастила

Как рассчитать угол наклона кровли из профнастила.

Расчет профнастила на крышу – точность и аккуратность

Расчет профнастила на вальмовую крышу

Все статьи

Как сделать шаг обрешетки под профнастил, крепление и устройство контробрешетки под металлопрофиль, фотопримеры и видео

Главная
›
Профнастил, профлист

Содержание статьи:

1. Установка обрешетки
2. Крепление профнастила к обрешетке
3. Параметры профиля профлиста

Одним из самых ответственных моментов при установке профлиста является создание каркаса, на который кровля будет стелиться. Для того чтобы обрешетка смогла выдерживать значительные нагрузки и правильно распределять вес кровли, она должна быть достаточно крепкой, как и вся стропильная система (прочитайте также: “Шаг стропил под профнастил”). Обрешетка под профлист выполняется путем установки брусьев или досок на опору с дальнейшим монтажом на них кровельного материала. Обрешетка под металлопрофиль позволяет ускорить процесс монтажа листов, так как значительно упрощается крепление кровли. Также обрешетка позволяет организовать правильную систему вентиляции в подкровельном пространстве.

Устройство обрешетки под профнастил можно проводить с использованием разных материалов. Для частных домов наиболее распространенна обрешетка из дерева, в случае с промышленными зданиями гораздо эффективнее использовать металлический каркас для крыши. Это позволяет выдерживать большие по сравнению с частным домом нагрузки на систему обрешетки.

Толщина досок или брусьев зависит от того, какой шаг обрешетки под профнастил был выбран. Он в свою очередь зависит от типа металлопрофиля.

Установка обрешетки

Рассмотрим как сделать обрешетку под профнастил. Основную доску обрешетки, которая будет проходить вдоль карниза, всегда берут толще остальных. В местах, где планируется установить выход вентиляции, дымохода или пожарного люка устанавливают дополнительные доски. Обрешетка крыши под профнастил устанавливается поверх слоя гидро- и теплоизоляции. Также важно вывести вентиляцию.

Шаг обрешетки под металлопрофиль не должен быть меньше 50 см, так это влечет за собой неоправданные затраты материалов. Размер шага зависит от типа металлопрофиля и его толщины. В торцах крыши устанавливают ветровые доски, которые должны защищать металлопрофиль от порывов ветра. Эти доски должны устанавливаться выше обрешетки на величину высоты профиля профнастила. На шаг обрешетки также влияют предполагаемые статические и динамические нагрузки в виде снега и ветра. Читайте также: “Как правильно сделать обрешетку под профнастил, шаг, крепление”.

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

Крепление профнастила к обрешетке

Профнастил крепят к обрешетке специальными саморезами для металлопрофиля, которые имеют уплотнительную шайбу. Закручивание саморезов необходимо проводить в нижней части листа. При этом, на 1 квадратный метр профлиста уходит примерно 7-8 саморезов. Между собой профилированные листы скрепляются либо заклепками, либо короткими кровельными саморезами.

Если обрешетка была установлена правильно, то вес металлопрофиля равномерно распределится по конструкции, что позволяет кровле выдерживать тяжелые снежные массы и не прогибаться под их действием.

Параметры профиля профлиста

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

В частном строительстве распространено применение профлиста с высотой гофры 35 мм и толщиной основания 0,6-0,7 мм. Профиль подобного рода позволяет организовать обрешетку с шагом до 150 см, при этом предельная нагрузка на 1 кв.м материала составляет 600 кг. Столь высокая прочность материала позволяет вполне безбоязненно передвигаться по нему строителям (прочтите статью: “Параметры и виды металлопрофиля”).

При выборе профнастила с низкой высотой гофры (до 21 мм), то есть применяя «плоский» металлопрофиль, обрешетка делается с минимально возможным шагом или вообще сплошной (детальнее: “Сплошная обрешетка кровли: устройство и монтаж”). Такие листы не рассчитаны на значительные нагрузки, а поэтому прочность конструкции будет гораздо ниже. Хотя подобный «плоский» профнастил позволяет собрать кровлю за очень короткий срок (читайте ещё: “Как рассчитать профнастил крышу”).

Монтаж обрешетки, подробно на видео:

Профиль с высотой более 44 мм применяют в промышленном строительстве, в котором обрешетка и контробрешетка под профнастил не всегда обязательны.

Руководство по капельникам для черепичных крыш – Нужны ли капельники?

Руководство по капельным кромкам для черепичных крыш — нужна ли капельная кромка? – ИКО Перейти к основной навигации перейти к содержанию Перейти к нижнему колонтитулу

Содержание

Для чего нужны водосточные желоба?
Типы материала капельной кромки
Типы профиля капельной кромки
Как установить капельницу
Как заменить отлив на существующей крыше

Капельницы представляют собой металлические листы, обычно в форме буквы «L», устанавливаемые на краю крыши. Также называемые окантовкой капельницы или D-металлом, они выполняют жизненно важную функцию, направляя воду от фасции в водосточный желоб. Без капельницы вода может попасть под черепицу и нанести ущерб различным частям дома. Хотя изначально в вашем доме может не быть установлен отлив, в настоящее время большинство строительных норм и правил Северной Америки требуют отливов для защиты домов от повреждений.

Для чего нужны водосточные желоба?

Капельницы служат двум основным целям:

Направление воды от лицевой панели: Из-за сцепления, поверхностного натяжения и других сил капли воды имеют тенденцию прилипать друг к другу и к поверхностям, на которых они находятся, хотя и незначительно. Капельница предназначена для использования этих сил и, наряду с гравитацией, направляет воду в желоб. Если в доме нет водосточного желоба, водосточная кромка предотвратит стекание воды по фасции на полость софита или в нее. Однако без капельницы вода прилипает к черепице, потенциально проникая под нее и вызывая протечку. Например, вода может прилипнуть к облицовке, что может привести к гниению или, в тяжелых условиях, к протечке в дом.
Защита от дождя с ветром: В тяжелых условиях ветер гонит воду по крыше. Черепица, а также подложка и защита от льда и воды не дают дождю с ветром повредить настил крыши. Однако на краях капельница должна конкурировать с ветром. Ветер может легко подтолкнуть воду вверх, прежде чем гравитация потянет воду вниз. Край капельницы должен значительно свисать с края крыши и иметь от двух до четырех дюймов нижнего фланца для борьбы с этим. И, конечно же, без капельницы дождь с ветром может испортить крышу.

Типы материалов кромок капель

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

Алюминий: Распространенный материал для капельниц, алюминий не такой прочный, как сталь. Он не подвергается коррозии и часто продается в цветах, точно соответствующих остальной части дома.
Оцинкованная сталь: Капельницы предназначены для контакта с водой; так, если они сделаны из стали, их нужно оцинковать, чтобы предотвратить ржавчину. Предпочтительна сталь минимум 24 калибра, чтобы кромка капельницы могла выдерживать сильный ветер.
Медь: Медь — это прочный металл, который придает крыше неповторимый вид. При использовании в качестве капельницы она должна быть не менее 0,69 мм или 20 унций.

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

Типы профиля капельной кромки

Существует три основных профиля капельной кромки, но каждый имеет несколько названий, что может сбивать с толку.

Тип C: Это классическая L-образная капельница, которую иногда называют L-образной. Эта капельная кромка изогнута под углом 90 градусов и имеет нижний фланец внизу.
Тип D: Этот профиль капельницы имеет форму буквы «Т» с нижним фланцем внизу. Иногда его называют дрип-метал, «Д-метал» или «Т-стиль». Ассоциация производителей асфальтовых кровель (ARMA) предпочитает этот профиль водосточной кромки типу C, потому что он удерживает воду дальше от фасции. Тем не менее, тип C по-прежнему приемлем в соответствии с большинством строительных норм и правил.
Тип F: Это удлиненный капельник с более длинной передней кромкой, что полезно при установке новых капельников поверх существующей черепицы или на передние кромки. Этот профиль часто называют «стиль F» или «фартук желоба».

Тип C: Это классическая L-образная капельница, которую иногда называют L-образной.

Тип D: Этот профиль капельницы имеет форму буквы «Т» с нижним фланцем внизу.

Водосточные кромки обычно продаются длиной 10,5 футов, но иногда они продаются длиной 8 футов или меньше. Длина самого выступа обычно колеблется от 2 до 5 дюймов. В магазине вы можете найти другие стили и размеры капельников, в том числе «J-образные» капельники, но они предназначены для окон, дверей и других применений. Вы также можете найти вентилируемые капельницы, но Национальная ассоциация кровельных подрядчиков (NRCA) не рекомендует использовать их на крышах.

Как установить капельницу

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

Шаг первый: Если вы используете капельницу типа C, вы можете установить обрешетку, чтобы улучшить ее характеристики. Кромка обрешетки — это полоса дерева один на два, которую вы устанавливаете на вертикальную поверхность дома прямо под краем крыши. Когда вы устанавливаете капельницу поверх этой полосы, она удерживает нижний фланец дальше от сайдинга дома, что помогает удерживать воду дальше от дома.
Шаг второй: Сначала установите капельники на карнизы. Поместите край капельницы вниз, выровняв его так, чтобы вода стекала в желоба. Конец с фланцем или раструбом должен быть направлен вниз и в сторону от крыши.
Шаг третий: Используйте кровельные гвозди, чтобы закрепить кромку капельника. Прибейте высоко к краю капельницы, чтобы черепица покрывала гвозди. В идеале вы должны забивать примерно каждые 12 дюймов, и ни при каких обстоятельствах у вас не должно быть 16 дюймов или более между гвоздями. Когда вы размещаете следующую часть края капельницы, она должна перекрывать первую на дюйм.

Шаг второй: Сначала установите капельники на карнизы.

Шаг третий: Используйте кровельные гвозди, чтобы закрепить капельник. В идеале вы должны забивать примерно каждые 12 дюймов, и ни при каких обстоятельствах у вас не должно быть 16 дюймов или более между гвоздями.

Шаг четвертый: Когда вы дойдете до угла, где встречаются свес и передний край, вам нужно сделать надрез, чтобы обеспечить правильную посадку. Во-первых, поместите край капельницы на край граблей. Отметьте, где край капельницы начинает выступать и на один дюйм дальше от этого выступа.
Шаг пятый: Обрежьте всю капельницу по второй отметке, чтобы она выступала за край всего на дюйм. Затем отрежьте самую верхнюю часть края капельницы по первой отметке. Затем сделайте перпендикулярный надрез, чтобы можно было удалить квадрат края капельницы, как показано на изображении ниже.
Шаг шестой: Установите капельницу как обычно. Затем согните край капельницы, чтобы получился уголок. Вы завершите этот угол, когда будете устанавливать края капельницы на грабли.
Изображение предоставлено CASMA
Шаг седьмой: После того, как вы покрыли карниз отливом, пришло время установить подложку. Таким образом, подложка находится над кромкой капельника на карнизе, но под кромкой капельницы на граблях.

Шаг шестой: Установите капельницу как обычно.
Изображение предоставлено CASMA

Шаг седьмой : После того, как вы покрыли карниз отливом, пришло время установить подложку.

Шаг восьмой: Затем установите капельницы на грабли. Используйте гвозди, как и раньше.
Шаг девятый: Когда вы дойдете до угла, где сходятся передний край и край карниза, просто установите водосборник граблей поверх откидной створки, которую вы оставили при установке водосливного края карниза.

Шаг девятый: Установите кромку капельницы поверх створки

Шаг одиннадцатый: Сложите кромку капельницы, чтобы она поместилась над коньком.

Шаг десятый: Когда вы дойдете до конька крыши, вам нужно сделать еще один надрез в кромке капельника. Поднесите край капельника к коньку и сделайте отметку там, где край капельника выходит за пределы крыши. Сделайте прямой надрез в нижней части капельницы ножницами по металлу.
Шаг одиннадцатый: Сложите край капельницы, чтобы он подходил к коньку. Отметьте отвесную линию или осевую линию, как на изображении ниже. Отрежьте самую верхнюю часть края капельницы по этой линии, чтобы создать законченный вид. Вставьте один гвоздь во внешнюю часть, чтобы удерживать край капельницы на месте.

Вы всегда должны сверяться с местными строительными нормами и правилами, чтобы узнать, существуют ли какие-либо дополнительные правила, которым необходимо следовать при установке капельницы.

Как заменить отлив на существующей крыше

Что делать, если вам нужно заменить отлив на существующей крыше или впервые установить отлив на существующей крыше? Это можно сделать; Вот как это сделать:

Шаг первый: Аккуратно поднимите черепицу по краю крыши и найдите гвозди, удерживающие существующую кромку водостока на крыше.
Шаг второй: С помощью плоской монтировки и молотка осторожно вытащите гвозди из края капельницы.
Шаг третий: Освободив капельницу, сдвиньте ее наружу и выбросьте.
Шаг четвертый : Установите новую капельницу, как описано выше, с помощью цемента и гвоздей. Вам нужно будет попросить другого кровельщика придержать черепицу, пока вы это делаете.

Так же, как и при установке капельников на новых крышах, вы должны свериться с местными строительными нормами и правилами, чтобы узнать, существуют ли специальные правила, которым вы должны следовать при замене капельников.

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

Если вы обнаружили, что на вашей крыше отсутствует водослив или он поврежден, вы можете связаться с подрядчиком по кровельным работам, воспользовавшись нашей системой поиска подрядчиков по кровельным работам, чтобы получить профессиональную консультацию.

В видео ниже представлена дополнительная информация об установке капельника на кровле из гонта:

Информация на этом веб-сайте может быть изменена без предварительного уведомления. IKO не несет ответственности за ошибки, которые могут появиться на этом веб-сайте.

IKO стремится точно воспроизвести экранные изображения образцов гонта и фотографий дома. Однако из-за производственных отклонений, ограничений разрешения вашего монитора и различий в естественном внешнем освещении фактические цвета могут отличаться от изображений, которые вы видите. Чтобы гарантировать полное удовлетворение, вы должны сделать окончательный выбор цвета из нескольких полноразмерных гонтов и просмотреть образец продукта, установленного на доме. Пожалуйста, ознакомьтесь с нашими юридическими уведомлениями для США или нашими юридическими уведомлениями для Канады.

Местоположение установлено для просмотра всех.

IKO производит продукцию для определенных регионов Северной Америки.

Чтобы убедиться, что мы предлагаем продукты, доступные в вашем регионе, выберите свою страну и штат/провинцию.

Выберите страну Выберите странуUSACanada

Выберите провинцию Выберите провинциюАльбертаБританская КолумбияМанитобаНью-БрансуикНьюфаундленд и ЛабрадорНовая ШотландияОнтариоОстров принца ЭдуардаКвебекСаскачеванСеверо-Западные территорииНунавутЮконВыберите провинцию Select StateAlabamaAlaskaArizonaArkansasCaliforniaColoradoConnecticutDelawareDistrict Of ColumbiaFloridaGeorgiaHawaiiIdahoIllinoisIndianaIowaKansasKentuckyLouisianaMaineMarylandMassachusettsMichiganMinnesotaMississippiMissouriMontanaNebraskaNevadaNew HampshireNew JerseyNew MexicoNew YorkNorth CarolinaNorth DakotaOhioOklahomaOregonPennsylvaniaRhode IslandSouth CarolinaSouth DakotaTennesseeTexasUtahVermontVirginiaWashingtonWest VirginiaWisconsinWyoming

Показать все продукты

ПРИМЕЧАНИЕ. Не все представленные продукты будут доступны в вашем регионе.

Как установить конек металлической кровли

Металлическая кровля конек – это накладка, укладываемая вдоль конька крыши – пика, где сходятся два ската крыши.

Наконечник конька обычно устанавливается только после того, как все металлические панели крыши и любая другая отделка установлены на место. Другими словами, его надевают в последнюю очередь – шапку на работу.

Большая часть конька поставляется в виде кусков длиной 10 футов 6 дюймов. Они предназначены для покрытия 10-футового конька с 6-дюймовым перекрытием между частями.

Металлочерепица

Для предотвращения попадания мусора, насекомых и метель в зазоры между панелями и коньком используются закрывающие планки. Затворы бывают двух типов: сплошные и вентилируемые .

Прочные заглушки , также называемые «внешними заглушками», обычно изготавливаются из плотного вспененного материала. Они поставляются в виде кусков длиной 3 фута, предназначенных для плотного прилегания к ребрам панелей крыши. Их укладывают встык и закрепляют по краю верхнего ряда панелей, где панели и накладка конька соприкасаются. Каждая часть также предназначена для соединения со следующей. Соединяясь встык, они образуют непрерывный, водонепроницаемый и воздухонепроницаемый барьер.

Вентилируемая крышка или «профильная вентиляция» имеет профиль, аналогичный сплошным крышкам, и соответствует ребристому рисунку кровельных панелей. Один распространенный тип имеет ширину 3 дюйма и поставляется в рулонах длиной 50 футов. Вентилируемое закрытие помогает предотвратить попадание насекомых и воды, а также позволяет горячему воздуху легко выходить из чердака.

Наконечник конька металлической кровли – этапы установки

Отцентрируйте кусок наголовника на коньке здания. Сделайте отметку на нижних краях колпачка (с обеих сторон), на одном конце ребра. См. рисунок ниже.
Если длина конька составляет всего 15–20 футов, повторите шаг 1 на противоположном конце конька. Для более длинного гребня двигайтесь вдоль гребня, повторяя шаг 1 каждые 15 футов или около того, пока не достигнете противоположного конца.
Отложите заглушку в сторону и проведите мелом линию между отметками. У вас должно получиться 2 отметки мелом – по одной с каждой стороны конька и по всей его длине.
Следуя приведенным ниже шагам a-c, разместите наружные закрывающие полосы (или вентилируемые затворы) по всей длине конька с обеих сторон крыши. Край крышки должен быть на 1/4 дюйма выше меловой линии (то есть на 1/4 дюйма ближе к пику). [Примечание: Шаги а-в дают один общий метод установки крышек. Прежде чем начать, ознакомьтесь с инструкциями для вашей кровельной системы, так как они могут отличаться.]
- Проложите полосу герметизирующей ленты по всей длине конька, примерно на 1 дюйм выше меловой линии. Повторите на противоположной стороне. Если вдоль верхней части полоски герметика имеется бумажная подложка, удалите ее.
- Закрывающие полоски по всей длине конька, соединяя их встык по ходу движения и прижимая поверх герметизирующей ленты.
- Протяните еще одну полосу герметизирующей ленты по верху закрывающих полосок. Оставьте бумажную подложку на месте.

Вентилируемая крышка устанавливается почти таким же образом, за исключением того, что ее разворачивают, а не укладывают на 3-футовые части.

5. Начиная с конца конька, где была установлена первая панель, установите первую часть заглушки конька.

Ознакомьтесь с проектом и инструкциями для вашей конкретной крыши, чтобы определить, следует ли размещать заглушку конька заподлицо с концом конька или с выступом. На приведенном ниже примере показан коньковый выступ, выступающий на ½ дюйма за край крыши.

Не допуская, чтобы заглушка конька касалась какой-либо оголенной герметизирующей ленты, отцентрируйте ее прямо поверх конька, используя сам ребро и линии, нанесенные ранее мелом, в качестве ориентиров.

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

6. Прикрепите конек к нижним панелям. На приведенном ниже примере винты расположены так, чтобы проходить через центр каждого второго основного ребра панели крыши. Вам нужно будет проконсультироваться с инструкциями для вашей конкретной крыши для таких деталей.

7. Наложите следующий кусок гребня на 6″ на первый и повторите шаги 5 и 6.

8. Продолжайте движение вниз по гребню, пока не дойдете до его конца. Возможно, потребуется обрезать последнюю часть гребня конька, чтобы он соответствовал длине вашего конька.

Другие типы металлической кровли и конька

Приведенные выше шаги объясняют установку стального кровельного конька для наиболее распространенных конструкций металлической кровли и конька. Существуют и другие типы, такие как панели со стоячим фальцем и гонт, коньковые коньки с вентиляцией, коньковые коньки светового люка и формованные коньковые коньки. Подробная информация о том, как установить эти специальные типы, приведена в инструкциях, которые должны прилагаться к ним, и в других статьях.

Для получения дополнительной информации об установке металлической кровли посетите сайт Metal Roofing Source

Пожалуйста, позвоните нам по бесплатному номеру 1-877-833-3237

, если у вас есть вопросы или предложения! Мы здесь, чтобы помочь.

Служба поддержки клиентов и цены доступны с 8:00 до 17:00 по тихоокеанскому времени с понедельника по пятницу.

Как провести аудит в социальных сетях (бесплатный шаблон)

Маркетинг в социальных сетях — это сплошное развлечение и игра, пока не придет время измерить ваши результаты, верно? Не бойтесь: аудит социальных сетей — ваш лучший бизнес.

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

В этом посте объясняется, как провести эффективный аудит социальных сетей от начала до конца. У нас даже есть удобный (и бесплатный) шаблон аудита в социальных сетях, который упрощает задачу.

1. Создайте список всех ваших учетных записей в социальных сетях.

2. Проверьте свой брендинг

3. Определите ваш самый эффективный контент в социальных сетях

4. Оцените эффективность каждого канала

5. Изучите свою аудиторию на каждой платформе

6. Примите меры: обновите свою маркетинговую стратегию в социальных сетях

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

Что такое аудит социальных сетей?

Аудит социальных сетей — это процесс измерения успеха вашей социальной стратегии в разных учетных записях и сетях. Он определяет ваши сильные и слабые стороны и следующие шаги, необходимые для улучшения ваших результатов в будущем.

Аудит социальных сетей предоставит вам четкую стратегию для всех ваших каналов социальных сетей и информацию, необходимую для оптимизации маркетинга в социальных сетях.

Вы знаете:

Ваши самые эффективные платформы,
Что ваша аудитория хочет видеть в каждой сети,
Кто ваша аудитория (демография и т. д.),
Что помогает увеличить вашу аудиторию (а что нет),
Как каждая платформа способствует достижению ваших целей,
Какие новые идеи помогут вам расти,
И на что обратить внимание дальше.

Как провести аудит социальных сетей за 7 шагов

Если вы готовы начать прямо сейчас, загрузите приведенный выше бесплатный шаблон аудита социальных сетей и следуйте инструкциям.

1. Создайте список всех своих учетных записей в социальных сетях

Вы можете подумать, что знаете все свои учетные записи в социальных сетях наизусть, но есть вероятность, что вы забываете одну или две. Начните с перечисления всех ваших профилей в социальных сетях, включая все неактивные.

Не полагайтесь на записи компании, чтобы раскрыть все эти счета. Что, если другой отдел решит завести отдельный аккаунт, никому ничего не сказав? Единственный способ узнать это немного покопаться.

Где найти эту информацию:

Найдите в каждой крупной социальной сети названия вашего бренда и продукта, чтобы увидеть, не обнаружите ли вы какие-либо неожиданные учетные записи, например старые тестовые учетные записи. Упс.

Затем составьте план действий по обнаружению проблемных учетных записей. От старых тестовых, созданных вашей компанией, вероятно, не составит труда избавиться (или переключиться на приватные настройки), хотя найти старую информацию для входа может быть непросто.

Если учетные записи самозванцев или другие лица нарушают ваши материалы, защищенные авторским правом, скорее всего, вместо вас этим будет заниматься юридический отдел. Тем не менее, запишите шаги, необходимые для решения каждой из них. Для некоторых это может быть так же просто, как связаться с владельцами поддельных учетных записей или сообщить об учетной записи в социальную сеть, в которой она находится.

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

В дополнение к учетным записям, которые у вас есть, подумайте о тех, которых у вас нет. Есть ли социальные платформы, на которых вы не представлены? Стоит ли начинать делать танцы в TikTok? (Должен ли кто-нибудь?) А как насчет Nextdoor? Или Байт?

Вам не нужно быть в каждой сети, но аудит — это хорошее время, чтобы добавить новые идеи в вашу социальную стратегию на будущее. Если вы не уверены, по крайней мере зарезервируйте свое бизнес-имя пользователя на новых платформах, чтобы никто не опередил вас.

2. Проверьте свой брендинг

Просмотрите каждый профиль, чтобы убедиться, что все они соответствуют вашим текущим рекомендациям по стилю бренда. Это включает в себя изображения вашего профиля и баннеров, хэштеги, копии и фразы, голос бренда, URL-адреса и многое другое.

Вот ключевые области для оценки каждой социальной учетной записи:

Изображения профиля и обложки. Убедитесь, что ваши изображения отражают ваш текущий брендинг и соответствуют требованиям каждой социальной сети к размеру изображения.

Текст профиля/биографии. У вас ограниченное пространство для работы при создании биографии в социальных сетях, поэтому важно максимально использовать его. Все ли поля заполнены правильно? Соответствует ли текст в вашем разделе «о себе» вашему тону и правилам голоса?
Имя пользователя. Используете ли вы одно и то же имя пользователя во всех социальных сетях? Это хорошая идея, если вы можете. Конечно, у вас может быть более одной учетной записи в сети, если они служат разным целям. (Например, наши аккаунты в Твиттере @Hootsuite и @Hootsuite_Help. )
Ссылки. URL-адрес в вашем профиле указывает на правильный веб-сайт или целевую страницу?
Закрепленные сообщения (если применимо). Оценивайте закрепленные сообщения, чтобы убедиться, что они по-прежнему актуальны и актуальны.
Проверка. Подтверждена ли ваша учетная запись синей галочкой? Если нет, то стоит ли попробовать? У нас есть руководства о том, как именно пройти проверку в Instagram, Twitter и Facebook, если вы хотите этим заниматься.

3. Определите ваш самый эффективный контент в социальных сетях

Для каждого социального профиля укажите пять ваших самых популярных сообщений. Скопируйте ссылки на сообщения в свой шаблон аудита социальных сетей, чтобы вы могли легко просмотреть их позже.

Что делает «самую эффективную публикацию»? Мы предлагаем ранжировать их по уровню вовлеченности, чтобы найти контент, который больше всего нравится вашей аудитории. Однако вы можете выбрать другую ключевую метрику, на которой следует сосредоточиться, например клики по ссылкам или конверсии.

Просмотрите свои топовые посты на наличие шаблонов. Перефразируя слова Снуп Догга, сосредоточьтесь на своей метрике 9.0137 (и ваша метрика на уме) и спросите себя:

Что дает вам желаемый ответ? Посты с фотографиями? Видео? Лента, истории или ролики?
Что вызывает наибольшую вовлеченность: откровенный, закулисный контент или полированные и профессиональные посты?
Одинаково ли люди реагируют во всех сетях или контент определенного типа работает лучше на одной платформе, чем на других?
Взаимодействуют ли люди с вашими сообщениями, если вы задаете вопрос?
Соответствуют ли ваши топовые публикации голосу вашего текущего бренда? (Если нет, и они играют хорошо, возможно, пришло время переоценить этот голос.)

Используйте колонку примечаний в своем аудиторском документе, чтобы записывать свои мысли. Мы вернемся к этим заметкам позже в процессе аудита, чтобы обсудить новые стратегии социального маркетинга.

Где найти эту информацию:

Вы можете использовать встроенные инструменты аналитики для каждой социальной сети, чтобы сортировать и находить самые популярные публикации по выбранному вами ключевому показателю. Не знаете как? У нас есть полные руководства по использованию всех из них:

Руководство по аналитике Twitter
Руководство по аналитике Facebook
Руководство по аналитике Instagram
Руководство по аналитике TikTok
Руководство по аналитике LinkedIn
Руководство по аналитике Pinterest
Руководство по аналитике Snapchat

Но подождите: это может занять вечность. Сделайте жизнь проще и используйте Hootsuite Analytics, чтобы найти самые популярные публикации для всех ваших учетных записей социальных сетей в одном месте всего за несколько кликов.

Hootsuite Analytics предоставляет ценную информацию для информирования вашей социальной стратегии как во время этого аудита, так и постоянно:

Попробуйте Hootsuite бесплатно. (Вы можете отменить в любое время.)

Узнайте больше о том, как использовать Hootsuite Analytics, из этого 2-минутного видео.

4. Оцените эффективность каждого канала

Теперь пришло время взглянуть на каждую из ваших социальных учетных записей с расстояния 10 000 футов. На этом этапе оценивается вклад каждого социального канала в достижение ваших общих маркетинговых целей.

Получите бесплатный шаблон прямо сейчас!

Если вы еще не создали формулировку миссии и несколько ключевых целей для каждой социальной учетной записи, сейчас самое время.

У нескольких учетных записей могут быть схожие цели, например увеличение веб-трафика и конверсий. Другие могут быть предназначены исключительно для целей обслуживания клиентов или повышения узнаваемости бренда. Например, наша учетная запись на YouTube посвящена обучению продуктам, а наша учетная запись @Hootsuite_Help в Twitter предназначена только для технической поддержки:

Для каждого канала укажите его цели и отслеживайте прогресс в их достижении. Для измеримых целей, таких как трафик или конверсии, запишите фактические цифры.

Сколько посещений сайта было из Instagram? Сколько продаж поступило от посетителей Страницы Facebook? Если целью является обслуживание клиентов, запишите свой балл CSAT и посмотрите, улучшается ли он со временем. Быть конкретной.

Для целей без количественных данных запишите подтверждающие доказательства. Если ваша учетная запись Facebook предназначена для повышения узнаваемости бренда, увеличилось ли число ваших подписчиков? Вы увеличили свой органический или платный охват?

Суть здесь в том, чтобы понять назначение каждого из ваших социальных каналов и измерить их эффективность.

Где найти эту информацию:

Поиск актуальной информации будет зависеть от целей, которые вы ставите для каждого канала. Для целей обслуживания клиентов или узнаваемости бренда использование инструментов социального прослушивания дает вам данные от реальных клиентов.

Для целей трафика или конверсии большая часть этой информации содержится в Google Analytics. Вы можете просмотреть разбивку трафика по каналам (плюс гораздо больше информации), перейдя в Acquisition -> Social -> Network Referrals.

Отслеживание конверсий из социальных сетей — не точная наука, хотя на одних каналах это проще, чем на других. Например, вам нужно настроить Meta Pixel (ранее Facebook Pixel), чтобы отслеживать данные о конверсиях Facebook, и многие сети имеют свои собственные коды отслеживания. Многие платформы электронной коммерции также имеют встроенное отслеживание социальных каналов.

Еще раз, вы можете сделать свою жизнь намного проще, используя для этого инструмент управления социальными сетями, такой как Hootsuite Analytics. Вот краткий обзор того, как это работает, в том числе как эффективно отслеживать конверсии с помощью повторяющихся отчетов, которые вы можете запустить за несколько секунд:

Попробуйте Hootsuite бесплатно. (Вы можете отменить в любое время.)

5. Изучите свою аудиторию на каждой платформе

Теперь, когда вы знаете, как каждая учетная запись помогает поддерживать и развивать ваш бренд, важно понимать, кого вы достигаете на каждой платформе.

Демографические данные аудитории — хорошая отправная точка. Например, Instagram привлекает большое внимание своими функциями электронной коммерции, но на самом деле потребители тратят больше всего денег на TikTok. Facebook — самая популярная платформа для людей в возрасте 35–44 лет, но YouTube — это место для группы 18–25 лет.

Хотя ваша аудитория может отличаться от нормы, мы собрали все основные демографические данные для каждой социальной сети, чтобы вы могли начать:

Демография Facebook
Демография Twitter
Демографические данные в Instagram
Демография TikTok
Демографические данные LinkedIn
Демографические данные Snapchat
Демографические данные Pinterest
Демографические данные YouTube

Изучите демографию вашей уникальной аудитории на каждой платформе и используйте ее вместе с типами сообщений, которые они предпочитают, для создания портретов покупателей. Не волнуйтесь, у нас есть бесплатный шаблон портрета покупателя, который также облегчит вам задачу.

Где найти эту информацию:

Как и другие показатели, о которых мы говорили, вы можете найти демографическую информацию в отчетах каждой платформы или, что гораздо проще, с помощью комплексных отчетов об аудитории в Hootsuite Insights.

6. Примите меры: обновите свою маркетинговую стратегию в социальных сетях

Теперь, когда вы знаете свои цели и текущую эффективность для каждой платформы, подумайте, как ее улучшить. Пересматривайте свои заметки из предыдущих шагов, когда планируете следующий месяц или квартал вперед.

Задайте себе несколько вопросов:

Какие платформы приносят наибольшую пользу?
Есть ли какие-либо новые платформы социальных сетей, которые вам следует использовать?
Вы игнорируете какие-либо платформы? Нужны ли они вам вообще, или было бы лучше использовать ваше время, чтобы бросить их и сосредоточиться на более эффективных?
Какие типы контента сейчас работают лучше всего? Как вы можете сделать больше из этого?

Подумайте о новом контенте и идеях для кампаний, опираясь на то, что вы узнали из основного контента на третьем этапе. Если видео пользуется большим успехом, запишите конкретную стратегию, чтобы больше использовать его в своем маркетинге. Это может быть «Публикуйте 3 новых ролика в Instagram в неделю» или «Переделайте существующее длинное видео в короткие 15-секундные клипы для социальных сетей».

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

Каждую новую стратегию и идею записывайте в свой маркетинговый план. (У вас его еще нет? У нас есть еще один замечательный шаблон: этот бесплатный документ с планом маркетинга в социальных сетях.) Ваша маркетинговая стратегия — это живой документ: обновляйте ее.

Где найти эту информацию:

Твой мозг! Используйте все данные, которые вы уже собрали, чтобы генерировать новые идеи. Держите перед собой цели для каждой платформы, чтобы вы могли связать с ними обновленный маркетинговый план. Не забудьте сообщить другим, когда вы обновите маркетинговый план, чтобы все были на одной странице.

Как только вы закончите проверку… запланируйте следующую! Придерживайтесь обычного графика. Ежеквартально подходит для большинства компаний, хотя, если вы запускаете много кампаний или каналов, вы можете захотеть проверять ежемесячно.

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

Бесплатный шаблон аудита социальных сетей

Лучший способ отслеживать информацию об аудите социальных сетей (и все в жизни) — использовать электронную таблицу.

Мы создали для вас готовый шаблон аудита социальных сетей. Загрузите его выше или создайте свой собственный со следующими полями:

Данные учетной записи:

ваше имя пользователя
ссылка на ваш профиль
о/био текст для аккаунта
любые хэштеги, которые появляются в вашей биографии или которые вы будете регулярно использовать
URL-адрес для использования в вашей биографии
независимо от того, подтверждена ваша учетная запись или нет
внутреннее лицо или команда, ответственная за управление учетной записью (также известная как «владелец» — например, команда социального маркетинга)
Миссия учетной записи (например: «Продвигать культуру компании с помощью фотографий сотрудников» или «Обеспечивать обслуживание клиентов»).
сведения о текущем закрепленном сообщении (если применимо)
дата последнего сообщения (чтобы помочь вам определить недостаточно используемые/заброшенные учетные записи)

Сведения о производительности:

общее количество опубликованных постов
показателей вовлеченности: уровень вовлеченности, рейтинг кликов, просмотры, комментарии, публикации и т. д.
изменение уровня вовлеченности по сравнению с вашим последним аудитом
пять лучших постов для каждой платформы по показателю вовлеченности (или ключевой метрике, которую вы выбрали)
ROI вашей кампании (необязательно, если вы запускаете платную рекламу)

Сведения об аудитории:

демографические данные и характеристики покупателей
количество подписчиков (и изменение +/- по сравнению с вашим последним аудитом)

Цели:

2-3 S.M.A.R.T. цели, которых вы хотите достичь к следующему аудиту
достигли ли вы целей, поставленных перед этим аудитом, или изменили курс (и почему)

Теперь вы знаете все, что нужно для проведения собственного аудита социальных сетей. Иди и анализируй!

Экономьте время, управляя всеми своими учетными записями в одном месте с помощью Hootsuite. Планируйте контент и кампании, планируйте публикации, управляйте разговорами и просматривайте всю свою аналитику и данные о рентабельности инвестиций с помощью быстрых автоматических отчетов. Включите свой социальный маркетинг сегодня.

Начните бесплатную 30-дневную пробную версию

Вся аналитика ваших социальных сетей в одном месте . Используйте Hootsuite, чтобы увидеть, что работает и где можно улучшить производительность.

Бесплатная 30-дневная пробная версия

Как вычислить промежуточный итог в Excel

Промежуточный итог, также известный как кумулятивная сумма, является широко используемой функцией в сфере образования и бизнеса.
Процесс создания промежуточного итога в Excel состоит из трех простых шагов.
Промежуточные итоги используются в розничных магазинах, на распродажах и на спортивных мероприятиях и т.д.
Эта статья предназначена для владельцев бизнеса и профессионалов, которые хотят узнать, как создать промежуточный итог в Microsoft Excel.

Создать промежуточный итог (или кумулятивную сумму, как это известно в Excel) легко, как только вы освоите его. Многие владельцы бизнеса используют кумулятивные суммы для отслеживания расходов и доходов, рабочего времени сотрудников и управления запасами.

Идея промежуточного итога состоит в том, чтобы взять столбец чисел и рядом с ним показать промежуточный итог этих чисел. Вы можете использовать как положительные, так и отрицательные числа в промежуточной сумме, поэтому при желании вы можете сложить свои продажи и изъятия.

Что такое промежуточный итог?

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

Как создать промежуточный итог в Excel

1. Начните с =СУММ. Нажмите на ячейку, с которой вы хотите, чтобы ваша промежуточная сумма начиналась. Затем выберите функцию СУММ в этой ячейке. Но вместо выделения ячеек в круглых скобках (путем перетаскивания курсора по ячейкам, которые вы хотите включить в уравнение), как если бы вы добавляли столбец чисел, вам нужно создать так называемую «абсолютную ссылку», за которой следует по «относительной ссылке». Не волнуйся; это не так сложно, как кажется. Следующий шаг описывает, как это сделать.

2. Создайте формулу промежуточного итога. В этой формуле необходимо использовать знак доллара, даже если подсчитываемые числа не являются суммами в долларах. Допустим, в нашем образце рабочей книги Excel вы хотите, чтобы совокупный итог был размещен в столбце C. В ячейке C1 вы должны ввести =СУММ($B$2:B2). Это создает необходимую относительную контрольную точку (B2) и абсолютную контрольную точку ($B$2) для вашего текущего подсчета.

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

3. Щелкните правый нижний угол ячейки с формулой. Затем перетащите вниз до тех пор, пока не будет применен промежуточный итог. Когда формула перетаскивается вниз, абсолютная контрольная точка $B$2 остается неизменной. Относительная контрольная точка B2 изменяется по мере того, как вы перетаскиваете курсор вниз до B3, B4, B5 и т. д.

Например, если стоимость продаж в марте составляет 500 долл. значение 700 долларов, вы введете эти значения в столбец «Продажи». Чтобы получить промежуточную сумму, введите 500 долларов в верхнем правом столбце и используйте приведенную выше формулу для расчета промежуточной суммы. Затем вы перетащите курсор вниз, чтобы охватить продажи за апрель, май и июнь. Затем промежуточная сумма будет отображать 500, 1150 и 1850 долларов соответственно. Затем у вас будет промежуточная сумма, к которой вы сможете добавлять ежемесячные значения продаж с течением времени. Вот и все.

Как можно использовать промежуточный итог?

Хотя это вычисление может показаться немного сложным, на самом деле это довольно распространенная концепция, с которой многие из нас регулярно сталкиваются, независимо от того, используем ли мы ее. Вот некоторые примеры использования промежуточной суммы:

Операции с кассовым аппаратом.

Одним из наиболее распространенных примеров промежуточных сумм, с которыми вы регулярно сталкиваетесь, является использование кассовых аппаратов. В частности, кассовые аппараты отображают промежуточную сумму различных продуктов по мере их сканирования в систему. Кроме того, они обычно подсчитывают все транзакции, совершенные в течение дня.

В кассовом аппарате может быть предусмотрена функция отчетности, показывающая промежуточные итоги повседневных функций в магазине, включая количество покупателей в определенное время дня и самые популярные товары за день или за все время, в зависимости от категории. Использование промежуточного итога позволяет розничным магазинам выявлять тенденции среди покупателей и улучшать свою работу.

Игровые табло.

Еще одним распространенным применением промежуточных сумм являются табло на спортивных мероприятиях. Хотя вы видите каждое очко, когда оно попадает на доску, чтобы понять, как рассчитывается конечный счет, в конце концов, окончательный счет — это единственное значение, которое имеет значение. Кроме того, игра в крикет, в частности, является отличным примером промежуточного итога. Каждый раз, когда игрок забивает ран, он добавляется к общему количеству. Таким образом, общий балл — это просто промежуточный итог или сумма прогонов.

Позиции по продажам

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

Менеджеры могут использовать эти промежуточные итоги для ежемесячной, ежеквартальной или годовой оценки производительности. Эти промежуточные итоги также могут определять реальную производительность по отношению к целевым показателям с течением времени. Затем эти данные можно использовать для устранения неполадок, которые необходимо изменить, если цели не достигнуты.

Расчеты с начала года

Одно из самых популярных применений промежуточных сумм — это расчеты с начала года. Расчет с начала года (с начала года) используется для записи определенной функции или деятельности (обычно финансовой) с определенной даты до конца года.

Например, вы можете увидеть массив расчетов за текущий год в своих платежных квитанциях. Это пример промежуточного итога, поскольку он отслеживает различные сделанные платежи и собранные налоги, чтобы дать вам окончательную сумму в конце каждого года. Эти окончательные итоги затем переносятся в формы W-2 и используются для целей налогообложения. Расчеты за текущий год также используются для расчета дохода от аренды, финансового положения бизнеса или доходности акций.

Итоги запасов

Другим распространенным применением промежуточных сумм является метод, используемый компанией для отслеживания запасов. Компании должны записывать количество проданных товаров и сравнивать это число с тем, сколько товаров у них есть на складе, так что это пример промежуточной суммы. Например, если в начале недели у вас есть на складе 1000 файлов cookie, каждая продажа будет вычитаться из общего запаса, и после каждой транзакции будет подсчитываться новая сумма.

Бухгалтерские балансы.

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

Балансы на банковских счетах

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

Расход бензина

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

Подсчет калорий

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

Синтаксис рабочего процесса для действий GitHub

О синтаксисе YAML для рабочих процессов

Файлы рабочего процесса используют синтаксис YAML и должны иметь расширение .yml или .yaml . Если вы новичок в YAML и хотите узнать больше, см. раздел «Изучите YAML за Y минут».

Вы должны хранить файлы рабочих процессов в каталоге .github/workflows вашего репозитория.

имя

Имя вашего рабочего процесса. GitHub отображает имена ваших рабочих процессов на вкладке «Действия» вашего репозитория. Если пропустить name , GitHub задает для него путь к файлу рабочего процесса относительно корня репозитория.

run-name

Имя для запусков рабочего процесса, созданное из рабочего процесса. GitHub отображает имя запуска рабочего процесса в списке запусков рабочего процесса на вкладке «Действия» вашего репозитория. Если вы опустите имя-запуска , имя запуска задается для информации о событии для запуска рабочего процесса. Например, для рабочего процесса, запущенного push или pull_request 9.0817, оно устанавливается как сообщение фиксации.

Это значение может включать выражения и может ссылаться на контексты ввода и github и .

Пример

 run-name: Разверните в ${{ inputs.deploy_target }} с помощью @${{ github.actor }}

на

Чтобы автоматически запустить рабочий процесс, используйте на , чтобы определить, какие события могут вызвать запуск рабочего процесса. Список доступных событий см. в разделе «События, запускающие рабочие процессы».

Можно определить одно или несколько событий, которые могут запускать рабочий процесс, или установить расписание. Вы также можете ограничить выполнение рабочего процесса только для определенных файлов, тегов или изменений ветки. Эти параметры описаны в следующих разделах.

Использование одного события

Например, рабочий процесс со следующим значением на будет запущен при отправке в любую ветвь в репозитории рабочего процесса:

 на: push

Использование нескольких событий

Можно указать одно или несколько событий. Например, рабочий процесс со следующим значением на будет запущен, когда будет сделана отправка в любую ветвь в репозитории или когда кто-то разветвит репозиторий:

 на: [push, fork]

Если указать несколько событий, только одно из них должно произойти, чтобы запустить рабочий процесс. Если одновременно происходит несколько инициирующих событий для вашего рабочего процесса, будет запущено несколько запусков рабочего процесса.

Использование видов деятельности

Некоторые события имеют типы активности, которые дают вам больше контроля над тем, когда должен запускаться ваш рабочий процесс. Используйте on..types , чтобы определить тип действия события, которое будет запускать рабочий процесс.

Например, событие issue_comment имеет созданных , отредактированных и удаленных типов действий. Если ваш рабочий процесс запускается по событию метки , он будет выполняться всякий раз, когда метка создается, редактируется или удаляется. Если указать создал тип активности для события label , ваш рабочий процесс будет запускаться при создании метки, но не при редактировании или удалении метки.

 по:
  этикетка:
    типы:
      - созданный

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

 на:
  вопросы:
    типы:
      - открыт
      - помечен

Дополнительные сведения о каждом событии и их типах действий см. в разделе «События, запускающие рабочие процессы».

`Использование фильтров`

Некоторые события имеют фильтры, которые дают вам больше контроля над тем, когда должен запускаться ваш рабочий процесс.

Например, событие push имеет фильтр ветвей , который запускает ваш рабочий процесс только тогда, когда происходит отправка ветки, которая соответствует фильтру ветвей , а не когда происходит какое-либо нажатие.

 на:
  толкать:
    ветви:
      - главный
      - 'релизы/**'

`Использование типов действий и фильтров с несколькими событиями`

Если вы указываете типы действий или фильтры для события, а ваш рабочий процесс запускается для нескольких событий, вы должны настроить каждое событие отдельно. Вы должны добавлять двоеточие ( : ) ко всем событиям, включая события без настройки.

Например, рабочий процесс со следующим значением на будет выполняться, когда:

Создана этикетка
Производится отправка в основную ветку в хранилище
Отправка в ветку GitHub Pages с поддержкой

 по:
  этикетка:
    типы:
      - созданный
  толкать:
    ветви:
      - главный
  страница_сборка:

 on..types  Используйте  on..types , чтобы определить тип действия, запускающего рабочий процесс. Большинство событий GitHub инициируются более чем одним типом активности. Например,  метка  запускается, когда метка  создана  ,  отредактирована  или  удалена  . Ключевое слово  типов  позволяет сузить круг действий, вызывающих запуск рабочего процесса. Когда только один тип действия вызывает событие веб-перехватчика, ключевое слово  типов  не требуется.
 Вы можете использовать массив событий  типов  . Дополнительные сведения о каждом событии и их типах действий см. в разделе «События, запускающие рабочие процессы».
 по:
  этикетка:
    типы: [создано, отредактировано]
 
 on..  При использовании событий  pull_request  и  pull_request_target  рабочий процесс можно настроить так, чтобы он выполнялся только для запросов на вытягивание, нацеленных на определенные ветки.

Используйте фильтр ветвей , если вы хотите включить шаблоны имен ветвей или если вы хотите включить и исключить шаблоны имен ветвей. Используйте фильтр ветвей-игнорировать , если вы хотите исключить только шаблоны имен ветвей. Вы не можете использовать оба 9Ветви 0816 Ветви и — игнорировать фильтры для одного и того же события в рабочем процессе.

Если вы определите обе ветви / ветвей — игнорируйте пути и , рабочий процесс будет выполняться только тогда, когда оба фильтра будут удовлетворены.

Ветви и ветвей-игнорировать ключевые слова принимают шаблоны подстановок, которые используют такие символы, как * , ** , + , ? , ! и другие, чтобы соответствовать более чем одному названию ветки. Если имя содержит какой-либо из этих символов и вам нужно буквальное совпадение, вам нужно экранировать каждый из этих специальных символов с помощью \ . Дополнительные сведения о шаблонах глобусов см. в «Шпаргалке по шаблонам фильтров».

Пример: включая ветки

Шаблоны, определенные в ветвях , оцениваются по имени ссылки Git. Например, следующий рабочий процесс будет выполняться при наличии события pull_request для таргетинга запроса на вытягивание:

Ветвь с именем main ( refs/heads/main )
Ветвь с именем mona/octocat ( refs/heads/mona/octocat )
Ветка, название которой начинается с релизов/, например релизов/10 ( refs/heads/releases/10 )

 по:
  pull_request:
    # Последовательность паттернов, сопоставленных с refs/heads
    ветви:
      - главный
      - 'мона/октокот'
      - 'релизы/**'

Пример: исключение ветвей

Если шаблон соответствует шаблону ветвей — игнорировать , рабочий процесс не запустится. Шаблоны, определенные в веток оцениваются по имени Git ref. Например, следующий рабочий процесс будет выполняться всякий раз, когда возникает событие pull_request , если только запрос на вытягивание не нацелен на:

Ветвь с именем mona/octocat ( refs/heads/mona/octocat )
Ветка, имя которой соответствует релизам/**-альфа , например релизам/бета/3-альфа ( refs/heads/releases/beta/3-alpha )

 по:
  pull_request:
    # Последовательность паттернов, сопоставленных с refs/heads
    ветки-игнорировать:
      - 'мона/октокот'
      - 'релизы/**-альфа'

Пример: Включение и исключение ветвей

Нельзя использовать ветвей и ветвей — игнорировать для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны ветвей для одного события, используйте фильтр ветвей вместе с фильтром ! символов, чтобы указать, какие ветки следует исключить.

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

Порядок определения шаблонов имеет значение.

Соответствующий отрицательный шаблон (с префиксом ! ) после положительного совпадения исключит Git ref.
Совпадающий положительный шаблон после отрицательного совпадения снова будет включать ссылку Git.

Следующий рабочий процесс будет выполняться на событиях pull_request для запросов на вытягивание, нацеленных на выпусков/10 выпусков или /бета/мона , но не для запросов на вытягивание, предназначенных для выпусков /10-альфа или выпусков /бета/3-альфа , потому что отрицательный шаблон !релизы/**-альфа следует положительному образцу.

 по:
  pull_request:
    ветви:
      - 'релизы/**'
      - '!релизы/**-альфа'

on.push.

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

Используйте фильтр ветвей , если вы хотите включить шаблоны имен ветвей или если вы хотите включить и исключить шаблоны имен ветвей. Используйте фильтр ветвей-игнорировать , если вы хотите исключить только шаблоны имен ветвей. Вы не можете использовать обе ветви и ветвей — игнорируйте фильтры для одного и того же события в рабочем процессе.

Используйте фильтр тегов , если вы хотите включить шаблоны имен тегов или если вы хотите включить и исключить шаблоны имен тегов. Используйте 9Теги 0816 — игнорируйте фильтр , если вы хотите исключить только шаблоны имен тегов. Вы не можете использовать оба тега и теги — игнорировать фильтры для одного и того же события в рабочем процессе.

Если вы определите только тегов / тегов — игнорировать или только ветвей / ветвей — игнорировать , рабочий процесс не будет запускаться для событий, влияющих на неопределенную ссылку Git. Если вы не определяете ни тегов , ни тегов / — игнорировать или ветвей, ни ветвей / — игнорировать рабочий процесс будет запускаться для событий, влияющих либо на ветки, либо на теги. Если вы определите обе ветви / ветвей — игнорировать пути и , рабочий процесс будет выполняться только тогда, когда оба фильтра будут удовлетворены.

ветвей , ветвей-игнорировать , тегов и тегов-игнорировать ключевых слов принимают универсальные шаблоны, которые используют такие символы, как * , ** 7 6 , , , ! и другие, чтобы соответствовать более чем одному названию ветви или тега. Если имя содержит какой-либо из этих символов и вам нужно буквальное совпадение, вам нужно экранируйте каждого из этих специальных символов с помощью \ . Дополнительные сведения о шаблонах глобусов см. в «Шпаргалке по шаблонам фильтров».

Пример: включая ветки и теги

Шаблоны, определенные в ветвях и тегах , оцениваются по имени ссылки Git. Например, следующий рабочий процесс будет выполняться всякий раз, когда есть событие push для:

Ветвь с именем main ( refs/heads/main )
Ветка с именем mona/octocat ( refs/heads/mona/octocat )
Ветка, название которой начинается с релизов/, например релизов/10 ( refs/heads/releases/10 )
Тег с именем v2 ( refs/tags/v2 )
Тег, имя которого начинается с v1. , например v1. 9.1 ( ссылок/тегов/v1.9.1 )

 по:
  толкать:
    # Последовательность паттернов, сопоставленных с refs/heads
    ветви:
      - главный
      - 'мона/октокот'
      - 'релизы/**'
    # Последовательность шаблонов, сопоставленных с ссылками/тегами
    теги:
      - v2
      - v1.*

Пример: исключение ветвей и тегов

Если шаблон соответствует шаблону ветвей — игнорировать теги или — игнорировать теги , рабочий процесс не запускается. Шаблоны, определенные в ветвях и тегах , оцениваются по имени ссылки Git. Например, следующий рабочий процесс будет выполняться при наличии события push , если только событие push не предназначено для:

Ветвь с именем mona/octocat ( refs/heads/mona/octocat )
Ветка, имя которой соответствует релизам/**-альфа , например бета/3-альфа ( refs/релизы/бета/3-альфа )
Тег с именем v2 ( refs/tags/v2 )
Тег, имя которого начинается с v1. , например v1.9 ( ссылок/тегов/v1.9 )

 по:
  толкать:
    # Последовательность паттернов, сопоставленных с refs/heads
    ветки-игнорировать:
      - 'мона/октокот'
      - 'релизы/**-альфа'
    # Последовательность шаблонов, сопоставленных с ссылками/тегами
    теги-игнорировать:
      - v2
      - v1.*

Пример: включение и исключение ветвей и тегов

Нельзя использовать ветвей и ветвей — игнорировать для фильтрации одного и того же события в одном рабочем процессе. Точно так же вы не можете использовать теги и теги — игнорировать для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны ветвей или тегов для одного события, используйте фильтр ветвей или тегов вместе с фильтром ! символов, чтобы указать, какие ветки или теги следует исключить.

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

Порядок определения шаблонов имеет значение.

Соответствующий отрицательный шаблон (с префиксом ! ) после положительного совпадения исключит Git ref.
Совпадающий положительный шаблон после отрицательного совпадения снова будет включать ссылку Git.

Следующий рабочий процесс будет выполняться при отправке выпусков/10 или выпусков/бета/мона , но не выпусков/10-альфа или выпусков/бета/3-альфа , потому что отрицательный шаблон ! релизы/**-альфа следует положительному образцу.

 на:
  толкать:
    ветви:
      - 'релизы/**'
      - '!релизы/**-альфа'

on. .

При использовании событий push и pull_request можно настроить рабочий процесс для запуска в зависимости от того, какие пути к файлам изменены. Фильтры пути не оцениваются для отправки тегов.

Используйте фильтр путей , если вы хотите включить шаблоны путей к файлам или если вы хотите включить и исключить шаблоны путей к файлам. Используйте paths-игнорируйте фильтр , если вы хотите исключить только шаблоны путей к файлам. Нельзя использовать оба пути : и — игнорировать фильтры для одного и того же события в рабочем процессе.

Пути Пути и — игнорировать ключевые слова , принимать шаблоны подстановок, которые используют * и ** подстановочных знаков для соответствия более чем одному имени пути. Дополнительные сведения см. в «Шпаргалке по шаблону фильтра».

Пример: Включение путей

Если хотя бы один путь соответствует шаблону в фильтре путей , рабочий процесс запускается. Например, следующий рабочий процесс будет выполняться каждый раз, когда вы отправляете файл JavaScript ( .js ).

 по:
  толкать:
    пути:
      - '**.js'

Примечание: Если рабочий процесс пропускается из-за фильтрации путей, фильтрации ветвей или сообщения фиксации, проверки, связанные с этим рабочим процессом, останутся в состоянии «Ожидание». Запрос на вытягивание, для которого требуется, чтобы эти проверки были успешными, будет заблокирован от слияния. Дополнительные сведения см. в разделе «Обработка пропущенных, но обязательных проверок».

Пример: исключение путей

Если все имена путей совпадают с шаблонами в путях — игнорировать , рабочий процесс не запустится. Если какие-либо имена путей не соответствуют шаблонам в путях — игнорируйте , даже если некоторые имена путей соответствуют шаблонам, рабочий процесс будет запущен.

Рабочий процесс со следующим фильтром пути будет выполняться только для событий push , которые включают хотя бы один файл за пределами каталога docs в корне репозитория.

 по:
  толкать:
    пути-игнорировать:
      - 'документы/**'

Пример: Включение и исключение путей

Нельзя использовать пути и пути — игнорировать для фильтрации одного и того же события в одном рабочем процессе. Если вы хотите включить и исключить шаблоны путей для одного события, используйте фильтр путей вместе с фильтром ! символов, чтобы указать, какие пути следует исключить.

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

Порядок определения шаблонов имеет значение:

Соответствующий отрицательный шаблон (с префиксом ! ) после положительного совпадения исключает путь.
Совпадающий положительный шаблон после отрицательного совпадения снова включает путь.

Этот пример запускается каждый раз, когда событие push включает файл в каталоге подпроекта или его подкаталогах, если только файл не находится в каталоге .0816 подпроект/docs каталог. Например, отправка, которая изменила sub-project/index.js или sub-project/src/index.js , вызовет запуск рабочего процесса, но отправка изменит только sub-project/docs/readme.md . не буду.

 по:
  толкать:
    пути:
      - 'подпроект/**'
      - '!подпроект/документы/**'

Сравнение различий Git

Примечание: Если вы отправляете более 1000 коммитов или если GitHub не создает различия из-за тайм-аута, рабочий процесс будет выполняться всегда.

Фильтр определяет, должен ли выполняться рабочий процесс, оценивая измененные файлы и запуская их по списку путей — игнорировать или путей . Если файлы не изменены, рабочий процесс не запустится.

GitHub генерирует список измененных файлов, используя различия с двумя точками для push-уведомлений и различия с тремя точками для запросов на вытягивание:

Запросы на вытягивание: Различия с тремя точками — это сравнение между самой последней версией тематической ветки и фиксация, в которой тематическая ветка была в последний раз синхронизирована с базовой веткой.
Отправка в существующие ветки: Сравнение с двумя точками сравнивает головной и базовый SHA напрямую друг с другом.
Отправка в новые ветки: Различие с двумя точками относительно родителя предка самой глубокой фиксации отправлено.

Различия ограничены 300 файлами. Если есть измененные файлы, которые не соответствуют первым 300 файлам, возвращенным фильтром, рабочий процесс не будет запущен. Возможно, вам потребуется создать более конкретные фильтры, чтобы рабочий процесс выполнялся автоматически.

Дополнительные сведения см. в разделе «Сравнение ветвей в запросах на вытягивание».

on.schedule

on.schedule можно использовать для определения расписания рабочих процессов. Вы можете запланировать запуск рабочего процесса в определенное время UTC, используя синтаксис cron POSIX. Запланированные рабочие процессы запускаются при последней фиксации в стандартной или базовой ветке. Самый короткий интервал, с которым вы можете запускать запланированные рабочие процессы, — каждые 5 минут.

Этот пример запускает рабочий процесс каждый день в 5:30 и 17:30 UTC:

 на:
  расписание:
    # * — это специальный символ в YAML, поэтому вы должны заключить эту строку в кавычки.
    - cron: '30 5,17 * * *'

Один рабочий процесс может быть запущен несколькими событиями расписания . Вы можете получить доступ к событию расписания, которое инициировало рабочий процесс, через контекст github.event.schedule . В этом примере рабочий процесс запускается в 5:30 UTC каждый понедельник-четверг, но пропускается шаг Не в понедельник или среду в понедельник и среду.

 на:
  расписание:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'
вакансии:
  test_schedule:
    запуски: ubuntu-последняя
    шаги:
      - имя: Не в понедельник или среду
        если: github.event.schedule != '30 5 * * 1,3'
        run: echo "Этот шаг будет пропущен в понедельник и среду"
      - имя: Каждый раз
        run: echo "Этот шаг будет выполняться всегда"

Дополнительные сведения о синтаксисе cron см. в разделе «События, запускающие рабочие процессы».

on.workflow_call

Используйте on.workflow_call , чтобы определить входы и выходы для повторно используемого рабочего процесса. Вы также можете сопоставить секреты, доступные для вызываемого рабочего процесса. Дополнительные сведения о повторно используемых рабочих процессах см. в разделе «Повторное использование рабочих процессов».

on.workflow_call.inputs

При использовании ключевого слова workflow_call можно дополнительно указать входные данные, которые передаются вызываемому рабочему процессу из вызывающего рабочего процесса. Для получения дополнительной информации о ключевое слово workflow_call , см. «События, запускающие рабочие процессы».

В дополнение к доступным стандартным входным параметрам для on.workflow_call.inputs требуется параметр типа . Дополнительные сведения см. в разделе on.workflow_call.inputs..type .

Если параметр по умолчанию не установлен, значением ввода по умолчанию является false для логического значения, 0 для числа и "" для строки.

В вызываемом рабочем процессе вы можете использовать контекст inputs для ссылки на ввод.

Если вызывающий рабочий процесс передает ввод, не указанный в вызываемом рабочем процессе, это приводит к ошибке.

Пример

 на:
  рабочий_вызов:
    входы:
      имя пользователя:
        description: 'Имя пользователя, переданное из рабочего процесса вызывающего абонента'
        по умолчанию: 'джон-доу'
        требуется: ложь
        тип: строка
вакансии:
  печать-имя пользователя:
    запуски: ubuntu-последняя
    шаги:
      - имя: вывести имя входа в STDOUT
        run: echo Имя пользователя ${{ inputs.username }}

Дополнительные сведения см. в разделе «Повторное использование рабочих процессов».

on.workflow_call.inputs..type

Требуется, если ввод определен для ключевого слова on.workflow_call . Значение этого параметра представляет собой строку, указывающую тип данных ввода. Это должно быть одно из: логическое значение , число или строка .

on.workflow_call.outputs

Карта выходов для вызываемого рабочего процесса. Выходные данные вызываемого рабочего процесса доступны для всех нижестоящих заданий в вызывающем рабочем процессе. Каждый выход имеет идентификатор, необязательный 9Описание 0816, и значение . Значение должно быть установлено равным значению вывода задания в вызываемом рабочем процессе.

В приведенном ниже примере для этого повторно используемого рабочего процесса определены два выхода: workflow_output1 и workflow_output2 . Они сопоставляются с выходными данными job_output1 и job_output2 , оба из задания my_job .

Пример

 на:
  рабочий_вызов:
    # Сопоставьте выходные данные рабочего процесса с выходными данными задания
    выходы:
      рабочий_выход_1:
        description: "Вывод первого задания"
        значение: ${{ jobs.my_job.outputs.job_output1 }}
      рабочий_выход2:
        description: "Вывод второго задания"
        значение: ${{ jobs.my_job.outputs.job_output2 }}

Для получения информации о том, как ссылаться на выходные данные задания, см. jobs..outputs . Дополнительные сведения см. в разделе «Повторное использование рабочих процессов».

on.workflow_call.secrets

Карта секретов, которые можно использовать в вызываемом рабочем процессе.

В вызываемом рабочем процессе можно использовать контекст секретов для ссылки на секрет.

Если вызывающий рабочий процесс передает секрет, не указанный в вызываемом рабочем процессе, это приводит к ошибке.

Пример

 на:
  рабочий_вызов:
    секреты:
      токен доступа:
        description: «Токен, переданный из рабочего процесса вызывающего абонента»
        требуется: ложь
вакансии:
  передать секрет к действию:
    запуски: ubuntu-последняя
    шаги:
      - name: Передать полученный секрет действию
        использует: ./.github/actions/my-action
        с:
          токен: ${{ secrets.access-token }}

on.workflow_call.secrets.

Строковый идентификатор для связи с секретом.

on.workflow_call.secrets..required

Логическое значение, определяющее необходимость предоставления секрета.

on.workflow_run.

При использовании события workflow_run вы можете указать, в каких ветвях запускающий рабочий процесс должен выполняться, чтобы запустить ваш рабочий процесс.

Ветви и ветвей-игнорировать фильтры принимают шаблоны глобусов, которые используют такие символы, как *, **, +, ? , ! и другие, чтобы соответствовать более чем одному названию ветки. Если имя содержит какой-либо из этих символов и вам нужно буквальное совпадение, вам нужно экранировать каждого из этих специальных символов с помощью \ . Дополнительные сведения о шаблонах глобусов см. в «Шпаргалке по шаблонам фильтров».

Например, рабочий процесс со следующим триггером будет выполняться только тогда, когда рабочий процесс с именем Build выполняется в ветке, имя которой начинается с выпусков/ :

 на:
  рабочий_запуск:
    рабочие процессы: ["Сборка"]
    типы: [запрошено]
    ветви:
      - 'релизы/**'

Рабочий процесс со следующим триггером будет выполняться только в том случае, если рабочий процесс с именем Build выполняется в ветке, которая не имеет имени canary :

 на:
  рабочий_запуск:
    рабочие процессы: ["Сборка"]
    типы: [запрошено]
    ветки-игнорировать:
      - "канарейка"

Вы не можете использовать обе ветви и ветвей - игнорировать фильтрует одно и то же событие в рабочем процессе. Если вы хотите включить и исключить шаблоны ветвей для одного события, используйте фильтр ветвей вместе с фильтром ! символов, чтобы указать, какие ветки следует исключить.

Порядок определения шаблонов имеет значение.

Соответствующий отрицательный шаблон (с префиксом ! ) после положительного совпадения исключает ветвь.
Совпадающий положительный шаблон после отрицательного совпадения снова включает ветвь.

Например, рабочий процесс со следующим триггером будет запущен, когда рабочий процесс с именем Build запускается в ветке с именем выпусков/10 или выпусков/бета/мона , но не выпусков/10-альфа , выпусков/бета/3-альфа , или основной .

 по:
  рабочий_запуск:
    рабочие процессы: ["Сборка"]
    типы: [запрошено]
    ветви:
      - 'релизы/**'
      - '!релизы/**-альфа'

on.workflow_dispatch. inputs

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

Запущенный рабочий процесс получает входные данные в контексте inputs . Дополнительные сведения см. в разделе «Контексты».

Примечание . Рабочий процесс также будет получать входные данные в контексте github.event.inputs . Информация в контексте inputs и контексте github.event.inputs идентична, за исключением того, что inputs context сохраняет логические значения как логические вместо преобразования их в строки.

 по:
  workflow_dispatch:
    входы:
      логуровень:
        описание: 'Уровень журнала'
        требуется: правда
        по умолчанию: «предупреждение»
        тип: выбор
        опции:
        - Информация
        - предупреждение
        - отлаживать
      print_tags:
        description: 'True для печати в STDOUT'
        требуется: правда
        тип: логический
      теги:
        description: 'Теги тестового сценария'
        требуется: правда
        тип: строка
      Окружающая среда:
        description: 'Среда для запуска тестов'
        тип: окружающая среда
        требуется: правда
вакансии:
  тег печати:
    запуски: ubuntu-последняя
    если: ${{ inputs. print_tags }}
    шаги:
      - имя: распечатать входной тег в STDOUT
        run: echo Теги ${{ inputs.tags }}

разрешения

Вы можете использовать разрешения для изменения разрешений по умолчанию, предоставленных GITHUB_TOKEN , добавляя или удаляя доступ по мере необходимости, чтобы вы разрешали только минимально необходимый доступ. Дополнительные сведения см. в разделе «Аутентификация в рабочем процессе».

Разрешения можно использовать либо в качестве ключа верхнего уровня для применения ко всем заданиям в рабочем процессе, либо к определенным заданиям. Когда вы добавляете ключ разрешений в определенное задание, все действия и команды запуска в этом задании, которые используют GITHUB_TOKEN получить указанные вами права доступа. Дополнительные сведения см. в разделе jobs..permissions .

Доступные области и значения доступа:

 разрешения:
  действия: чтение|запись|нет
  проверяет: чтение|запись|нет
  содержимое: чтение|запись|нет
  развертывания: чтение|запись|нет
  id-токен: чтение|запись|нет
  проблемы: чтение|запись|нет
  обсуждения: читать|писать|нет
  пакеты: чтение|запись|нет
  страницы: чтение|запись|нет
  пулл-реквесты: чтение|запись|нет
  репозиторий-проекты: чтение|запись|нет
  события безопасности: чтение|запись|нет
  статусы: чтение|запись|нет

Если вы укажете доступ для любой из этих областей, для всех неуказанных будет установлено значение нет .

Вы можете использовать следующий синтаксис, чтобы определить доступ для чтения или записи для всех доступных областей:

 разрешения: чтение-все|запись-все

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

 разрешения: {}

Вы можете использовать ключ разрешений для добавления и удаления разрешений на чтение для разветвленных репозиториев, но обычно вы не можете предоставлять доступ на запись. Исключением из этого поведения является случай, когда пользователь с правами администратора выбрал Отправлять токены записи в рабочие процессы из параметра пулл-реквестов в настройках GitHub Actions. Дополнительные сведения см. в разделе «Управление настройками GitHub Actions для репозитория».

Пример: Назначение разрешений для GITHUB_TOKEN

В этом примере показаны разрешения, устанавливаемые для GITHUB_TOKEN , которые будут применяться ко всем заданиям в рабочем процессе. Всем разрешениям предоставляется доступ для чтения.

 имя: "Мой рабочий процесс"
на: [ нажать ]
разрешения: все для чтения
вакансии:
  ...

env

Карта переменных среды, доступных для шагов всех заданий в рабочем процессе. Вы также можете установить переменные среды, которые доступны только для шагов одного задания или для одного шага. Дополнительные сведения см. в разделе Задания ..env и задания ..steps[*].env .

Переменные в карте env не могут быть определены с точки зрения других переменных в карте.

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

Пример

 env:
  СЕРВЕР: производство

значения по умолчанию

Используйте значения по умолчанию для создания карты параметров по умолчанию, которые будут применяться ко всем заданиям в рабочем процессе. Вы также можете установить настройки по умолчанию, которые доступны только для задания. Дополнительные сведения см. в разделе jobs..defaults .

Если с одним и тем же именем определено несколько параметров по умолчанию, GitHub использует наиболее конкретный параметр по умолчанию. Например, параметр по умолчанию, определенный в задании, переопределит параметр по умолчанию с тем же именем, который определен в рабочем процессе.

defaults.run

Вы можете использовать defaults.run , чтобы предоставить опции shell по умолчанию и work-directory для всех run шагов рабочего процесса. Вы также можете установить параметры по умолчанию для запуска , которые доступны только для задания. Дополнительные сведения см. в разделе заданий..defaults.run . Вы не можете использовать контексты или выражения в этом ключевом слове.

Пример: Установить оболочку по умолчанию и рабочий каталог

 значения по умолчанию:
  бежать:
    оболочка: баш
    рабочий каталог: скрипты

параллелизм

Используйте параллелизм , чтобы гарантировать, что только одно задание или рабочий процесс, использующий одну и ту же группу параллелизма, будет выполняться одновременно. Группа параллелизма может быть любой строкой или выражением. Выражение может использовать только контекст github . Дополнительные сведения о выражениях см. в разделе «Выражения».

Вы также можете указать параллелизм на уровне задания. Дополнительные сведения см. в разделе jobs..concurrency .

Когда параллельное задание или рабочий процесс поставлены в очередь, если выполняется другое задание или рабочий процесс, использующий ту же группу параллелизма в репозитории, поставленное в очередь задание или рабочий процесс будет ожидающим . Любое ранее ожидающее задание или рабочий процесс в группе параллелизма будет отменено. Чтобы также отменить любое текущее задание или рабочий процесс в той же группе параллелизма, укажите отмена в процессе: правда .

Примеры: использование параллелизма и поведение по умолчанию

 параллелизм: staging_environment

 параллелизм: ci-${{ github.ref }}

Пример: использование параллелизма для отмены любого выполняемого задания или запуска

 параллелизма:
  группа: ${{github.ref}}
  отмена в процессе: правда

Пример: использование резервного значения

Если вы строите имя группы со свойством, определенным только для определенных событий, вы можете использовать резервное значение. Например, github.head_ref определяется только для событий pull_request . Если ваш рабочий процесс реагирует на другие события в дополнение к событиям pull_request , вам потребуется предоставить запасной вариант, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или выполняется только для событий pull_request ; если github.head_ref не определено, группа параллелизма будет использовать идентификатор запуска, который гарантированно будет уникальным и определенным для запуска.

 параллелизм:
  группа: ${{ github.head_ref || github.run_id }}
  отмена в процессе: правда

Пример. Отмена текущих заданий или запусков только для текущего рабочего процесса

Если у вас есть несколько рабочих процессов в одном репозитории, имена групп параллелизма должны быть уникальными для рабочих процессов, чтобы избежать отмены выполняемых заданий или запусков из других рабочих процессов. В противном случае любое ранее выполнявшееся или отложенное задание будет отменено независимо от рабочего процесса.

Чтобы отменить только текущие запуски одного и того же рабочего процесса, вы можете использовать свойство github.workflow для создания группы параллелизма:

 параллелизм:
  группа: ${{github.workflow}}-${{github.ref}}
  отмена в процессе: правда

заданий

Запуск рабочего процесса состоит из одного или нескольких заданий , которые по умолчанию выполняются параллельно. Для последовательного запуска заданий можно определить зависимости от других заданий с помощью ключевого слова jobs..needs .

Каждое задание выполняется в среде исполнителя, указанной параметром работает на .

Вы можете запускать неограниченное количество заданий, пока не выходите за пределы использования рабочего процесса. Дополнительные сведения см. в разделах «Ограничения использования и выставление счетов» для бегунов, размещенных на GitHub, и «О самостоятельных исполнителях» для ограничений на использование бегунов, размещенных на собственном хосте.

Если вам нужно найти уникальный идентификатор задания, выполняемого в рабочем процессе, вы можете использовать GitHub API. Дополнительные сведения см. в разделе «Задания рабочего процесса».

заданий.

Использовать jobs. , чтобы присвоить вашей работе уникальный идентификатор. Ключ job_id — это строка, а ее значение — карта данных конфигурации задания. Вы должны заменить строкой, уникальной для объекта jobs . должен начинаться с буквы или _ и содержать только буквенно-цифровые символы, - или _ .

Пример: создание заданий

В этом примере было создано два задания, и их job_id значения my_first_job и my_second_job .

 рабочих мест:
  моя_первая_работа:
    Название: Моя первая работа
  моя_вторая_работа:
    Название: Моя вторая работа

jobs. .name

Используйте jobs..name , чтобы задать имя для задания, которое отображается в пользовательском интерфейсе GitHub.

заданий..permissions

Для определенного задания можно использовать заданий..permissions , чтобы изменить разрешения по умолчанию, предоставленные GITHUB_TOKEN , добавляя или удаляя доступ по мере необходимости, чтобы вы разрешали только минимально необходимый доступ. Дополнительные сведения см. в разделе «Аутентификация в рабочем процессе».

Указав разрешение в определении задания, вы можете настроить другой набор разрешений для GITHUB_TOKEN для каждого задания, если это необходимо. Кроме того, вы можете указать разрешения для всех заданий в рабочем процессе. Сведения об определении разрешений на уровне рабочего процесса см. в разделе 9.0816 разрешения .

Доступные области и значения доступа:

 разрешения:
  действия: чтение|запись|нет
  проверяет: чтение|запись|нет
  содержимое: чтение|запись|нет
  развертывания: чтение|запись|нет
  id-токен: чтение|запись|нет
  проблемы: чтение|запись|нет
  обсуждения: читать|писать|нет
  пакеты: чтение|запись|нет
  страницы: чтение|запись|нет
  пулл-реквесты: чтение|запись|нет
  репозиторий-проекты: чтение|запись|нет
  события безопасности: чтение|запись|нет
  статусы: чтение|запись|нет

Если вы укажете доступ для любой из этих областей, все те, которые не указаны, будут установлены на нет .

 разрешения: чтение-все|запись-все

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

 разрешения: {}

Пример: установка разрешений для определенного задания

В этом примере показаны разрешения, устанавливаемые для GITHUB_TOKEN , которые будут применяться только к заданию с именем stale . Доступ на запись предоставляется для областей issue и pull-requests . Все остальные области не будут иметь доступа.

 вакансии:
  несвежий:
    запуски: ubuntu-последняя
    разрешения:
      вопросы: пишите
      пулл-реквесты: написать
    шаги:
      - использует: action/stale@v5

заданий..needs

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

Пример: Требование успешных зависимых заданий

 заданий:
  задание1:
  задание2:
    потребности: работа1
  задание3:
    потребности: [работа1, работа2]

В этом примере задание 1 должно быть успешно завершено до начала задание 2 , а задание 3 ожидает завершения задание 1 и задание 2 .

Задания в этом примере выполняются последовательно:

задание1
задание2
задание3

Пример: Не требуется успешных зависимых заданий

 заданий:
  задание1:
  задание2:
    потребности: работа1
  задание3:
    если: ${{ всегда() }}
    потребности: [работа1, работа2]

В этом примере job3 использует условное выражение always() , поэтому оно всегда выполняется после завершения job1 и job2 , независимо от того, были ли они успешными. Дополнительные сведения см. в разделе «Выражения».

заданий..if

Вы можете использовать задания ..if условное условие для предотвращения запуска задания, если условие не выполнено. Вы можете использовать любой поддерживаемый контекст и выражение для создания условия.

При использовании выражений в условном выражении if синтаксис выражения можно опустить ( ${{ }} ), поскольку GitHub автоматически оценивает условное выражение if как выражение. Дополнительные сведения см. в разделе «Выражения».

Пример: Запуск задания только для определенного репозитория

В этом примере используется , если используется для управления запуском задания производственно-развертывание . Он будет работать, только если репозиторий называется octo-repo-prod и находится в организации octo-org . В противном случае задание будет помечено как пропущено .

заданий..runs-on

Используйте заданий..runs-on , чтобы определить тип машины, на которой будет выполняться задание. Машина может быть запущена как на GitHub, так и на собственном сервере. Вы можете предоставить повторяет как одну строку или как массив строк. Если вы укажете массив строк, ваш рабочий процесс будет выполняться на локальном исполнителе, метки которого соответствуют всем указанным значениям запусков на , если они доступны. Если вы хотите запустить рабочий процесс на нескольких компьютерах, используйте задания ..strategy .

Выбор исполнителей, размещенных на GitHub

Если вы используете исполнители, размещенные на GitHub, каждое задание запускается в новом экземпляре образа исполнителя, заданного параметром 9.0816 работает на .

Доступные типы бегунов, размещенных на GitHub:

Образ бегуна	Метка рабочего процесса YAML	Примечания
Windows Server 2022	`windows-последняя версия` или `windows-2022`	Метка `Windows-Latest` в настоящее время использует образ исполнителя Windows Server 2022.
Виндовс Сервер 2019	`окна-2019`
Убунту 22.04	`Ubuntu-22.04`
Убунту 20. 04	`ubuntu-последняя версия` или `ubuntu-20.04`
Ubuntu 18.04 ^{[устарело]}	`Ubuntu-18.04`	Перейдите на `ubuntu-20.04` или `ubuntu-22.04` . Для получения дополнительной информации см. этот пост в блоге GitHub.
macOS Монтерей 12	`макос-12`
macOS Биг Сур 11	`macos-последний` или `macos-11`	Метка `macos-latest` в настоящее время использует образ бегуна macOS 11.
macOS Catalina 10.15 ^{[устарело]}	`макос-10.15`	Перейдите на `macOS-11` или `macOS-12` . Для получения дополнительной информации см. этот пост в блоге GitHub.

Примечание. Образы -latest runner — это последние стабильные образы, предоставляемые GitHub, и они могут быть не самой последней версией операционной системы, доступной у поставщика операционной системы.

Примечание. Бета-версии и устаревшие образы предоставляются «как есть», «со всеми ошибками» и «как доступно» и исключаются из соглашения об уровне обслуживания и гарантии. Бета-образы могут не покрываться службой поддержки клиентов.

Пример: Указание операционной системы

 запуски: ubuntu-последняя

Дополнительные сведения см. в разделе «О средствах выполнения, размещенных на GitHub».

Выбор автономных исполнителей

Чтобы указать для задания локального исполнителя, настройте run-on в файле рабочего процесса с метками автономного исполнителя.

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

Хотя метка с самостоятельным размещением не требуется, мы настоятельно рекомендуем указать ее при использовании самостоятельных исполнителей, чтобы гарантировать, что в вашем задании непреднамеренно не будут указаны какие-либо текущие или будущие исполнители, размещенные на GitHub.

Пример: Использование меток для выбора желоба

 запуски: [самостоятельный хостинг, Linux]

Дополнительные сведения см. в разделах «О самостоятельных средствах выполнения» и «Использование самостоятельных средств выполнения в рабочем процессе».

jobs..environment

Используйте jobs..environment , чтобы определить среду, на которую ссылается задание. Все правила защиты среды должны пройти, прежде чем задание, ссылающееся на среду, будет отправлено исполнителю. Дополнительные сведения см. в разделе «Использование сред для развертывания».

Вы можете указать среду только как среду с именем или как объект среды с именем и URL . URL-адрес сопоставляется с environment_url в API развертывания. Дополнительные сведения об API развертывания см. в разделе «Развертывания».

Пример: использование одного имени среды

 среда: staging_environment

Пример: Использование имени среды и URL-адреса

 среда:
  имя: production_environment
  адрес: https://github.com

URL-адрес может быть выражением и может использовать любой контекст, кроме контекста секретов . Дополнительные сведения о выражениях см. в разделе «Выражения».

Пример: использование вывода в качестве URL

 среда:
  имя: production_environment
  URL-адрес: ${{ steps.step_id.outputs.url_output }}

jobs..concurrency

Примечание. Если параллелизм указан на уровне задания, порядок заданий или запуска этой очереди не гарантируется в пределах 5 минут друг от друга.

Вы можете использовать заданий..concurrency , чтобы гарантировать, что одновременно будет выполняться только одно задание или рабочий процесс, использующий одну и ту же группу параллелизма. Группа параллелизма может быть любой строкой или выражением. Выражение может использовать любой контекст, кроме контекста секретов . Дополнительные сведения о выражениях см. в разделе «Выражения».

Можно также указать параллелизм на уровне рабочего процесса. Дополнительные сведения см. в разделе параллелизма .

Когда параллельное задание или рабочий процесс поставлены в очередь, если выполняется другое задание или рабочий процесс, использующий ту же группу параллелизма в репозитории, поставленное в очередь задание или рабочий процесс будет иметь статус в ожидании . Любое ранее ожидающее задание или рабочий процесс в группе параллелизма будет отменено. Чтобы также отменить любое текущее задание или рабочий процесс в той же группе параллелизма, укажите cancel-in-progress: true .

Примеры: использование параллелизма и поведение по умолчанию

 параллелизм: staging_environment

 параллелизм: ci-${{ github.ref }}

Пример: использование параллелизма для отмены любого выполняемого задания или запуска

 параллелизма:
  группа: ${{github.ref}}
  отмена в процессе: правда

Пример: использование резервного значения

Если вы строите имя группы со свойством, определенным только для определенных событий, вы можете использовать резервное значение. Например, github.head_ref определяется только для событий pull_request . Если ваш рабочий процесс реагирует на другие события в дополнение к pull_request событий, вам нужно будет предоставить запасной вариант, чтобы избежать синтаксической ошибки. Следующая группа параллелизма отменяет выполняемые задания или выполняется только для событий pull_request ; если github.head_ref не определено, группа параллелизма будет использовать идентификатор запуска, который гарантированно будет уникальным и определенным для запуска.

 параллелизм:
  группа: ${{ github.head_ref || github.run_id }}
  отмена в процессе: правда

Пример. Отмена текущих заданий или запусков только для текущего рабочего процесса

Чтобы отменить только текущие запуски одного и того же рабочего процесса, вы можете использовать свойство github.workflow для создания группы параллелизма:

 параллелизма:
  группа: ${{github. workflow}}-${{github.ref}}
  отмена в процессе: правда

jobs..outputs

Вы можете использовать jobs..outputs для создания карты выходных данных для задания. Выходные данные задания доступны для всех подчиненных заданий, которые зависят от этого задания. Дополнительные сведения об определении зависимостей заданий см. в разделе jobs..needs .

Выходные данные представляют собой строки Unicode и могут иметь размер не более 1 МБ. Суммарный размер всех выходных данных рабочего процесса может составлять не более 50 МБ.

Выходные данные задания, содержащие выражения, обрабатываются бегуном в конце каждого задания. Выводы, содержащие секреты, редактируются в исполнителе и не отправляются в GitHub Actions.

Чтобы использовать выходные данные задания в зависимом задании, вы можете использовать контекст need . Дополнительные сведения см. в разделе «Контексты».

Пример: определение выходных данных для задания

 задания:
  задание1:
    запуски: ubuntu-последняя
    # Сопоставьте вывод шага с выводом задания
    выходы:
      вывод1: ${{ шагов.шаг1.выходов.тест}}
      вывод2: ${{ шагов.шаг2.выходов.тест}}
    шаги:
      - идентификатор: шаг1
        запустить: echo "::set-output name=test::hello"
      - идентификатор: шаг2
        запустить: эхо "::set-output name=test::world"
  задание2:
    запуски: ubuntu-последняя
    потребности: работа1
    шаги:
      - выполнить: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}

jobs..env

Карта переменных среды, доступных для всех шагов задания. Вы также можете установить переменные среды для всего рабочего процесса или отдельного шага. Для получения дополнительной информации см. задания env и ..steps[*].env .

Пример

 заданий:
  задание1:
    среда:
      FIRST_NAME: Мона

заданий..defaults

Используйте заданий..defaults для создания карты настроек по умолчанию, которые будут применяться ко всем шагам задания. Вы также можете установить настройки по умолчанию для всего рабочего процесса. Дополнительные сведения см. в разделе по умолчанию .

заданий..defaults.run

Использовать заданий..defaults.run для предоставления оболочки по умолчанию и рабочего каталога для всех выполнения шагов задания. Контекст и выражения не допускаются в этом разделе.

Вы можете указать параметры shell по умолчанию и рабочего каталога для всех запусков шагов в задании. Вы также можете установить настройки по умолчанию для запуска для всего рабочего процесса. Для получения дополнительной информации см. jobs.defaults.run . Вы не можете использовать контексты или выражения в этом ключевом слове.

Пример: Настройка по умолчанию

выполнить параметров шага для задания

 заданий:
  задание1:
    запуски: ubuntu-последняя
    значения по умолчанию:
      бежать:
        оболочка: баш
        рабочий каталог: скрипты

jobs..steps

Задание содержит последовательность задач, называемую steps . Шаги могут запускать команды, запускать задачи установки или запускать действие в вашем репозитории, общедоступном репозитории или действие, опубликованное в реестре Docker. Не все шаги выполняют действия, но все действия выполняются как шаг. Каждый шаг выполняется в собственном процессе в среде исполнителя и имеет доступ к рабочей области и файловой системе. Поскольку шаги выполняются в своем собственном процессе, изменения переменных среды не сохраняются между шагами. GitHub предоставляет встроенные шаги для настройки и выполнения задания.

Вы можете выполнять неограниченное количество шагов, если вы находитесь в пределах использования рабочего процесса. Дополнительные сведения см. в разделах «Ограничения использования и выставление счетов» для бегунов, размещенных на GitHub, и «О самостоятельных исполнителях» для ограничений на использование бегунов, размещенных на собственном хосте.

Пример

 имя: Привет от Моны
на: нажать
вакансии:
  моя работа:
    Название: Моя работа
    запуски: ubuntu-последняя
    шаги:
      - имя: Распечатать приветствие
        среда:
          MY_VAR: Привет! Меня зовут
          FIRST_NAME: Мона
          MIDDLE_NAME:
          LAST_NAME: Октокот
        запустить: |
          эхо $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

jobs..steps[*].id

Уникальный идентификатор шага. Вы можете использовать идентификатор для ссылки на шаг в контекстах. Дополнительные сведения см. в разделе «Контексты».

jobs..steps[*].if

Вы можете использовать условие if , чтобы предотвратить выполнение шага, если условие не выполнено. Вы можете использовать любой поддерживаемый контекст и выражение для создания условия.

Когда вы используете выражения в , если условное выражение , вы можете опустить синтаксис выражения ( ${{ }} ), поскольку GitHub автоматически оценивает условное выражение , если как выражение. Дополнительные сведения см. в разделе «Выражения».

Пример: Использование контекстов

Этот шаг выполняется только в том случае, если типом события является pull_request , а действие события — unassigned .

 шагов:
 - название: Мой первый шаг
   если: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
   run: echo Это событие представляет собой запрос на вытягивание, в котором был удален уполномоченный.

Пример: Использование функций проверки состояния

Шаг моего резервного копирования запускается только в случае сбоя предыдущего шага задания. Дополнительные сведения см. в разделе «Выражения».

 шагов:
  - название: Мой первый шаг
    использует: octo-org/action-name@main
  - название: Мой резервный шаг
    если: ${{ сбой() }}
    использует: действия/героку@1.0.0

Пример: использование секретов

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

Если секрет не задан, возвращаемое значение выражения, ссылающегося на секрет (например, ${{ secrets.SuperSecret }} в примере), будет пустой строкой.

 имя: выполнить шаг, если был установлен секрет
на: нажать
вакансии:
  моя работа:
    запуски: ubuntu-последняя
    среда:
      super_secret: ${{ секреты.SuperSecret }}
    шаги:
      - если: ${{ env.super_secret != '' }}
        run: echo 'Этот шаг будет выполняться только в том случае, если для секрета установлено значение. '
      - если: ${{ env.super_secret == '' }}
        run: echo 'Этот шаг будет выполняться только в том случае, если для секрета не задано значение.'

Дополнительные сведения см. в разделах «Доступность контекста» и «Зашифрованные секреты».

jobs..steps[*].name

Имя вашего шага, которое будет отображаться на GitHub.

jobs..steps[*].uses

Выбирает действие, которое будет выполняться как часть шага вашего задания. Действие — это многократно используемая единица кода. Вы можете использовать действие, определенное в том же репозитории, что и рабочий процесс, в общедоступном репозитории или в опубликованном образе контейнера Docker.

Настоятельно рекомендуется указать используемую вами версию действия, указав тег Git ref, SHA или Docker. Если вы не укажете версию, это может нарушить ваши рабочие процессы или вызвать непредвиденное поведение, когда владелец действия публикует обновление.

Использование SHA фиксации выпущенной версии действия является самым безопасным для стабильности и безопасности.
Если действие публикует теги основных версий, следует ожидать получения критических исправлений и исправлений безопасности при сохранении совместимости. Обратите внимание, что такое поведение остается на усмотрение автора действия.
Использование ветви действия по умолчанию может быть удобным, но если кто-то выпустит новую основную версию с критическим изменением, ваш рабочий процесс может прерваться.

Для некоторых действий требуются входные данные, которые необходимо задать с помощью ключевого слова с . Просмотрите файл README действия, чтобы определить необходимые входные данные.

Действия — это либо файлы JavaScript, либо контейнеры Docker. Если действие, которое вы используете, является контейнером Docker, вы должны запустить задание в среде Linux. Подробнее см. работает на .

Пример: Использование версионных действий

 шагов:
  # Ссылка на конкретный коммит
  - использует: action/checkout@a81bbbf8298c0fa03ea29cdc473d45769f5
  # Ссылка на основную версию выпуска
  - использует: action/checkout@v3
  # Ссылка на конкретную версию
  - использует: action/checkout@v3. 2.0
  # Ссылка на ветку
  - использует: action/checkout@main

`Пример: использование общедоступного действия`

{owner}/{repo}@{ref}

Вы можете указать ветку, ссылку или SHA в общедоступном репозитории GitHub.

 вакансии:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        # Использует ветку общедоступного репозитория по умолчанию
        использует: action/heroku@main
      - название: Мой второй шаг
        # Использует определенный тег версии общедоступного репозитория
        использует: действия/[email protected]

`Пример: использование общедоступного действия в подкаталоге`

{владелец}/{репозиторий}/{путь}@{ref}

Подкаталог в общедоступном репозитории GitHub в определенной ветке, ссылке или SHA.

 вакансии:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        использует: действия/aws/ec2@main

`Пример: использование действия в том же репозитории, что и рабочий процесс`

. /path/to/dir

Путь к каталогу, содержащему действие в репозитории вашего рабочего процесса. Вы должны проверить свой репозиторий перед использованием действия.

 рабочих мест:
  моя_первая_работа:
    шаги:
      - имя: Проверить репозиторий
        использует: action/checkout@v3
      - имя: Использовать локальное мое действие
        использует: ./.github/actions/my-action

`Пример: использование действия Docker Hub`

docker://{image}:{tag}

Образ Docker, опубликованный в Docker Hub.

 рабочих мест:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        использует: докер://alpine:3.8

`Пример: использование реестра контейнеров пакетов GitHub`

docker://{host}/{image}:{tag}

Образ Docker в реестре контейнеров пакетов GitHub.

 рабочих мест:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        использует: docker://ghcr.io/OWNER/IMAGE_NAME

`Пример: использование действия общедоступного реестра Docker`

docker://{host}/{image}:{tag}

Образ Docker в общедоступном реестре. В этом примере используется реестр контейнеров Google по адресу gcr.io .

 рабочих мест:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        использует: docker://gcr.io/cloud-builders/gradle

`Пример: использование действия внутри частного репозитория, отличного от рабочего процесса`

Ваш рабочий процесс должен извлекать частный репозиторий и локально ссылаться на действие. Создайте токен личного доступа и добавьте токен в качестве зашифрованного секрета. Дополнительные сведения см. в разделах «Создание личного маркера доступа» и «Зашифрованные секреты».

Замените PERSONAL_ACCESS_TOKEN в примере на имя вашего секрета.

 рабочих мест:
  моя_первая_работа:
    шаги:
      - имя: Проверить репозиторий
        использует: action/checkout@v3
        с:
          репозиторий: octocat/my-private-repo
          ссылка: v1.0
          токен: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          путь: ./.github/actions/my-private-repo
      - имя: Запустить мое действие
        использует: . /.github/actions/my-private-repo/my-action

 jobs..steps[*].run  Запускает программы командной строки, используя оболочку операционной системы. Если вы не укажете имя   , именем шага по умолчанию будет текст, указанный в команде  run .
 По умолчанию команды выполняются с использованием оболочек без входа в систему. Вы можете выбрать другую оболочку и настроить оболочку, используемую для запуска команд. Дополнительные сведения см. в разделе  jobs..steps[*].shell  .
 Каждое ключевое слово  run  представляет новый процесс и оболочку в среде выполнения. Когда вы предоставляете многострочные команды, каждая строка выполняется в одной и той же оболочке. Например:
 Однострочная команда:
 — имя: Установить зависимости
  запустить: установка нпм
 
 Многострочная команда:
 - имя: Чистая установка зависимостей и сборка
  запустить: |
    нпм си
    npm запустить сборку
 
 С помощью ключевого слова  work-directory  можно указать рабочий каталог, в котором будет выполняться команда.
 - имя: Очистить временный каталог
  выполнить: пм -рф *
  рабочий каталог: ./temp
 
 jobs..steps[*].shell  Вы можете переопределить настройки оболочки по умолчанию в операционной системе исполнителя, используя ключевое слово  оболочки . Вы можете использовать встроенные ключевые слова оболочки   или определить собственный набор параметров оболочки. Команда оболочки, которая запускается внутри, выполняет временный файл, содержащий команды, указанные в ключевом слове  run .
 Опорная платформа   корпус  параметр  Описание  Внутренний запуск команды
 Linux / macOS  не указано  Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем при явном указании  bash . Если  bash  не найдено в пути, это рассматривается как  sh  .   bash -e {0} 
 Все   bash  Оболочка по умолчанию на платформах, отличных от Windows, с откатом до  sh  . При указании оболочки bash в Windows используется оболочка bash, включенная в Git для Windows.   bash --noprofile --norc -eo pipefail {0} 
 Все   pwsh  Ядро PowerShell. GitHub добавит расширение  .ps1  к имени вашего скрипта.   pwsh -command ". '{0}'" 
 Все   python  Выполняет команду python.   python {0} 
 Linux / macOS   sh  Резервное поведение для платформ, отличных от Windows, если не предоставлена оболочка и  bash  не найден в пути.   sh -e {0} 
 Windows   cmd  GitHub добавляет расширение  . cmd  к имени вашего скрипта и заменяет  {0}  .   %ComSpec% /D /E:ON /V:OFF /S /C "ВЫЗОВ "{0}""  .
 Windows   pwsh  Это оболочка по умолчанию, используемая в Windows. Ядро PowerShell. GitHub добавит расширение  .ps1  к имени вашего скрипта. Если на вашем локальном исполнителе Windows не установлен  PowerShell Core , вместо него используется  PowerShell Desktop .   pwsh -команда ". '{0}'"  .
 Windows   powershell  Рабочий стол PowerShell. GitHub добавит расширение  .ps1  к имени вашего скрипта.   powershell -команда ". '{0}'"  .
 Пример: Запуск скрипта с использованием bash 
 шагов:
  - имя: Показать путь
    запустить: эхо $PATH
    оболочка: баш
 
 Пример: Запуск скрипта с помощью Windows 
 cmd  шагов:
  - имя: Показать путь
    запустить: эхо %PATH%
    оболочка: cmd
 
 Пример: запуск скрипта с помощью PowerShell Core 
 шагов:
  - имя: Показать путь
    запустить: эхо ${env:PATH}
    оболочка: pwsh
 
 Пример: использование PowerShell Desktop для запуска сценария 
 шагов:
  - имя: Показать путь
    запустить: эхо ${env:PATH}
    оболочка: пауэршелл
 
 Пример: запуск скрипта Python 
 шагов:
  - имя: Показать путь
    запустить: |
      импорт ОС
      печать (os. environ ['ПУТЬ'])
    оболочка: питон
 
 Пользовательская оболочка

Опорная платформа	`корпус` параметр	Описание	Внутренний запуск команды
Linux / macOS	не указано	Оболочка по умолчанию на платформах, отличных от Windows. Обратите внимание, что при этом выполняется другая команда, чем при явном указании `bash` . Если `bash` не найдено в пути, это рассматривается как `sh` .	`bash -e {0}`
Все	`bash`	Оболочка по умолчанию на платформах, отличных от Windows, с откатом до `sh` . При указании оболочки bash в Windows используется оболочка bash, включенная в Git для Windows.	`bash --noprofile --norc -eo pipefail {0}`
Все	`pwsh`	Ядро PowerShell. GitHub добавит расширение `.ps1` к имени вашего скрипта.	`pwsh -command ". '{0}'"`
Все	`python`	Выполняет команду python.	`python {0}`
Linux / macOS	`sh`	Резервное поведение для платформ, отличных от Windows, если не предоставлена оболочка и `bash` не найден в пути.	`sh -e {0}`
Windows	`cmd`	GitHub добавляет расширение `. cmd` к имени вашего скрипта и заменяет `{0}` .	`%ComSpec% /D /E:ON /V:OFF /S /C "ВЫЗОВ "{0}""` .
Windows	`pwsh`	Это оболочка по умолчанию, используемая в Windows. Ядро PowerShell. GitHub добавит расширение `.ps1` к имени вашего скрипта. Если на вашем локальном исполнителе Windows не установлен PowerShell Core , вместо него используется PowerShell Desktop .	`pwsh -команда ". '{0}'"` .
Windows	`powershell`	Рабочий стол PowerShell. GitHub добавит расширение `.ps1` к имени вашего скрипта.	`powershell -команда ". '{0}'"` .

Вы можете установить значение оболочки в строку шаблона, используя команду […options] {0} [..more_options] . GitHub интерпретирует первое слово строки, разделенное пробелами, как команду и вставляет имя файла для временного скрипта по адресу {0} .

Например:

 шагов:
  - name: Показать переменные окружения и их значения
    запустить: |
      распечатать %ENV
    оболочка: перл {0}

Используемая команда, perl в этом примере, должна быть установлена на бегун.

Сведения о программном обеспечении, включенном в средства выполнения, размещенные на GitHub, см. в разделе «Спецификации средств выполнения, размещенных на GitHub».

`Коды выхода и предпочтения действий при ошибках`

Для ключевых слов встроенной оболочки мы предоставляем следующие значения по умолчанию, которые выполняются исполнителями, размещенными на GitHub. Вы должны использовать эти рекомендации при запуске сценариев оболочки.

баш / ш :
- Быстрый отказ с использованием set -eo pipefail : этот параметр устанавливается, когда 9Оболочка 0816: явно указан bash . По умолчанию не применяется.
- Вы можете получить полный контроль над параметрами оболочки, указав строку шаблона в параметрах оболочки. Например, bash {0} .
- sh-подобные оболочки завершают работу с кодом выхода последней команды, выполненной в сценарии, что также является поведением по умолчанию для действий. Бегун сообщит о статусе шага как неудача/успешно на основе этого кода выхода.
пауэршелл / пвш
- Отказоустойчивое поведение, когда это возможно. Для встроенной оболочки pwsh и powershell мы добавим $ErrorActionPreference = 'stop' к содержимому скрипта.
- Мы добавляем if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE } к сценариям powershell, чтобы статусы действий отражали последний код выхода сценария.
- Пользователи всегда могут отказаться, не используя встроенную оболочку и предоставив собственный вариант оболочки, например: pwsh -File {0} или powershell -Command "& '{0}'" , в зависимости от необходимости.
команда
- Похоже, что нет другого способа полностью выбрать отказоустойчивое поведение, кроме написания сценария для проверки каждого кода ошибки и соответствующего реагирования. Поскольку мы не можем обеспечить такое поведение по умолчанию, вам необходимо прописать это поведение в своем сценарии.
- cmd.exe завершится с уровнем ошибки последней выполненной программы и вернет код ошибки бегуну. Это поведение внутренне согласуется с предыдущими sh и pwsh поведение по умолчанию и cmd. exe по умолчанию, поэтому это поведение остается неизменным.

jobs..steps[*].with

Карта входных параметров, определенных действием. Каждый входной параметр представляет собой пару ключ/значение. Входные параметры задаются как переменные среды. Переменная имеет префикс INPUT_ и преобразуется в верхний регистр.

Пример

Определяет три входных параметра ( first_name , middle_name и last_name ), определенные действием hello_world . Эти входные переменные будут доступны для действия hello-world как переменные среды INPUT_FIRST_NAME , INPUT_MIDDLE_NAME и INPUT_LAST_NAME .

 рабочих мест:
  моя_первая_работа:
    шаги:
      - название: Мой первый шаг
        использует: действия/hello_world@main
        с:
          first_name: Мона
          отчество:
          last_name: Октокот

jobs. .steps[*].with.args

Строка , определяющая входные данные для контейнера Docker. GitHub передает аргументов в ENTRYPOINT контейнера при запуске контейнера. Массив строк не поддерживается этим параметром.

Пример

 шагов:
  - name: Объясните, почему эта работа выполнялась
    использует: octo-org/action-name@main
    с:
      точка входа: /bin/echo
      args: событие ${{ github.event_name }} инициировало этот шаг.

Аргументы используются вместо инструкции CMD в файле Dockerfile . Если вы используете CMD в своем Dockerfile , используйте рекомендации, упорядоченные по предпочтениям:

Документируйте необходимые аргументы в файле README действия и опускайте их в инструкции CMD .
Использовать значения по умолчанию, которые позволяют использовать действие без указания каких-либо аргументов .
Если действие предоставляет --help или что-то подобное, используйте его по умолчанию, чтобы ваше действие самодокументировалось.

jobs..steps[*].with.entrypoint

Переопределяет Docker ENTRYPOINT в файле Dockerfile или устанавливает его, если он еще не был указан. В отличие от инструкции Docker ENTRYPOINT , которая имеет форму оболочки и exec, ключевое слово entrypoint принимает только одну строку, определяющую исполняемый файл для запуска.

Пример

 шагов:
  - имя: Запустить пользовательскую команду
    использует: octo-org/action-name@main
    с:
      точка входа: /a/other/executable

Ключевое слово точка входа предназначено для использования с действиями контейнера Docker, но вы также можете использовать его с действиями JavaScript, которые не определяют никаких входных данных.

jobs.. steps[*].env

Задает переменные среды для шагов, которые будут использоваться в среде выполнения. Вы также можете установить переменные среды для всего рабочего процесса или задания. Для получения дополнительной информации см. env и заданий..env .

Публичные действия могут указывать ожидаемые переменные среды в файле README. Если вы устанавливаете секрет в переменной среды, вы должны установить секреты с помощью секретов контекста. Дополнительные сведения см. в разделах «Использование переменных среды» и «Контексты».

Пример

 шагов:
  - название: Мое первое действие
    среда:
      GITHUB_TOKEN: ${{ секреты.GITHUB_TOKEN }}
      FIRST_NAME: Мона
      LAST_NAME: Октокот

jobs..steps[*].continue-on-error

Предотвращает сбой задания при сбое шага. Установите значение true , чтобы разрешить выполнение задания в случае сбоя этого шага.

заданий..steps[*].timeout-minutes

Максимальное количество минут для выполнения шага перед уничтожением процесса.

jobs..timeout-minutes

Максимальное количество минут, в течение которого задание может выполняться, прежде чем GitHub автоматически отменит его. По умолчанию: 360

Если время ожидания превышает ограничение времени выполнения задания для бегуна, задание будет отменено, когда вместо этого будет достигнуто ограничение времени выполнения. Дополнительные сведения об ограничениях времени выполнения задания см. в разделах «Ограничения использования и выставление счетов» для исполнителей, размещенных на GitHub, и «О самостоятельных исполнителях» для ограничений на использование исполнителей, размещенных на собственном сервере.

Примечание: Срок действия GITHUB_TOKEN истекает после завершения задания или максимум через 24 часа. Для самостоятельных исполнителей токен может быть ограничивающим фактором, если время ожидания задания превышает 24 часа. Дополнительные сведения о GITHUB_TOKEN см. в разделе «О секрете GITHUB_TOKEN ».

заданий..strategy

Используйте заданий..strategy , чтобы использовать матричную стратегию для своих заданий. Матричная стратегия позволяет использовать переменные в одном определении задания для автоматического создания нескольких запусков задания на основе комбинаций переменных. Например, вы можете использовать матричную стратегию для тестирования своего кода в нескольких версиях языка или в нескольких операционных системах. Дополнительные сведения см. в разделе «Использование матрицы для ваших заданий».

заданий..strategy.matrix

Используйте заданий..strategy.matrix для определения матрицы различных конфигураций заданий. В вашей матрице определите одну или несколько переменных, за которыми следует массив значений. Например, следующая матрица содержит переменную version со значением [10, 12, 14] и переменную os со значением [ubuntu-latest, windows-latest] :

 job :
  пример_матрицы:
    стратегия:
      матрица:
        версия: [10, 12, 14]
        ОС: [ubuntu-последняя, Windows-последняя]

Задание будет выполняться для каждой возможной комбинации переменных. В этом примере рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации переменных os и версии .

По умолчанию GitHub максимизирует количество параллельно выполняемых заданий в зависимости от доступности исполнителя. Порядок переменных в матрице определяет порядок создания заданий. Первая переменная, которую вы определите, будет первым заданием, созданным в ходе вашего рабочего процесса. Например, приведенная выше матрица создаст задания в следующем порядке:

{версия: 10, ОС: ubuntu-последняя}
{версия: 10, ОС: последняя версия Windows}
{версия: 12, ОС: ubuntu-последняя}
{версия: 12, ОС: последняя версия Windows}
{версия: 14, ОС: ubuntu-последняя}
{версия: 14, ОС: последняя версия Windows}

Матрица создает не более 256 заданий за один запуск рабочего процесса. Это ограничение распространяется как на исполнителей, размещенных на GitHub, так и на собственных.

Определенные вами переменные становятся свойствами в контексте матрицы , и вы можете ссылаться на свойство в других областях файла рабочего процесса. В этом примере вы можете использовать matrix.version и matrix.os для доступа к текущему значению версии и os , которое использует задание. Дополнительные сведения см. в разделе «Контексты».

Пример: Использование одномерной матрицы

Вы можете указать одну переменную для создания одномерной матрицы.

Например, следующий рабочий процесс определяет переменную версии со значениями [10, 12, 14] . Рабочий процесс запустит три задания, по одному для каждого значения переменной. Каждое задание будет получать доступ к значению версии через контекст matrix.version и передавать значение как node-version в действие actions/setup-node .

 рабочих мест:
  пример_матрицы:
    стратегия:
      матрица:
        версия: [10, 12, 14]
    шаги:
      - использует: action/setup-node@v3
        с:
          версия узла: ${{ matrix. version }}

Пример: использование многомерной матрицы

Для создания многомерной матрицы можно указать несколько переменных. Задание будет выполняться для каждой возможной комбинации переменных.

Например, в следующем рабочем процессе указаны две переменные:

Две операционные системы, указанные в переменной os
Три версии Node.js, указанные в переменной версии

Рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации из os и версия переменные. Каждое задание установит значение run-on в текущее значение os и передаст текущее значение версии в действие action/setup-node .

 рабочих мест:
  пример_матрицы:
    стратегия:
      матрица:
        ОС: [убунту-22.04, убунту-20.04]
        версия: [10, 12, 14]
    запуски: ${{ matrix.os }}
    шаги:
      - использует: action/setup-node@v3
        с:
          версия узла: ${{ matrix. version }}

Пример: использование контекстов для создания матриц

Вы можете использовать контексты для создания матриц. Дополнительные сведения о контекстах см. в разделе «Контексты».

Например, следующий рабочий процесс запускается по событию relay_dispatch и использует информацию из полезной нагрузки события для построения матрицы. Когда событие отправки репозитория создается с полезной нагрузкой, подобной приведенной ниже, переменная matrix version будет иметь значение [12, 14, 16] . Для получения дополнительной информации о 9Триггер 0816 relay_dispatch , см. «События, запускающие рабочие процессы».

 {
  "тип_события": "тест",
  "client_payload": {
    "версии": [12, 14, 16]
  }
}

 по:
  репозиторий_отправка:
    типы:
      - тест
 
вакансии:
  пример_матрицы:
    запуски: ubuntu-последняя
    стратегия:
      матрица:
        версия: ${{ github.event.client_payload.versions }}
    шаги:
      - использует: action/setup-node@v3
        с:
          версия узла: ${{ matrix. version }}

jobs..strategy.matrix.include

Используйте jobs..strategy.matrix.include , чтобы расширить существующие матричные конфигурации или добавить новые конфигурации. Значение включает — это список объектов.

Для каждого объекта в списке include пары ключ:значение в объекте будут добавлены к каждой из комбинаций матриц, если ни одна из пар ключ:значение не перезапишет какие-либо исходные значения матрицы. Если объект не может быть добавлен ни к одной из комбинаций матриц, вместо нее будет создана новая комбинация матриц. Обратите внимание, что исходные значения матрицы не будут перезаписаны, но добавленные значения матрицы могут быть перезаписаны.

Например, эта матрица:

 стратегия:
  матрица:
    фрукты: [яблоко, груша]
    животное: [кошка, собака]
    включают:
      - цвет: зеленый
      - цвет: розовый
        животное: кошка
      - фрукты: яблоко
        форма: круг
      - фрукты: банан
      - фрукты: банан
        животное: кошка

приведет к шести заданиям со следующими комбинациями матриц:

{фрукт: яблоко, животное: кошка, цвет: розовый, форма: круг}
{фрукт: яблоко, животное: собака, цвет: зеленый, форма: круг}
{фрукт: груша, животное: кошка, цвет: розовый}
{фрукт: груша, животное: собака, цвет: зеленый}
{фрукт: банан}
{фрукт: банан, животное: кошка}

, следуя следующей логике:

{цвет: зеленый} добавляется ко всем исходным матричным комбинациям, поскольку его можно добавлять без перезаписи какой-либо части исходных комбинаций.
{цвет: розовый, животное: кошка} добавляет цвет:розовый только к исходным матричным комбинациям, которые включают животное: кошка . Это перезаписывает цвет : зеленый , который был добавлен предыдущей записью include .
{фрукт: яблоко, форма: круг} добавляет форма: круг только к исходным матричным комбинациям, которые включают фрукт: яблоко .
{фрукт: банан} нельзя добавить ни к одной исходной комбинации матриц без перезаписи значения, поэтому он добавляется как дополнительная комбинация матриц.
{фрукт: банан, животное: кошка} нельзя добавить ни к какой исходной комбинации матриц без перезаписи значения, поэтому он добавляется как дополнительная комбинация матриц. Он не добавляется к матричной комбинации {фрукты: банан} , потому что эта комбинация не была одной из исходных матричных комбинаций.

Пример: расширение конфигураций

Например, следующий рабочий процесс будет выполнять шесть заданий, по одному для каждой комбинации os и узел . При запуске задания для os со значением windows-latest и node со значением 16 в задание будет включена дополнительная переменная с именем npm со значением 6 .

 рабочих мест:
  пример_матрицы:
    стратегия:
      матрица:
        ОС: [Windows-последняя, Ubuntu-последняя]
        узел: [12, 14, 16]
        включают:
          - ОС: windows-последняя
            узел: 16
            нпм: 6
    запуски: ${{ matrix.os }}
    шаги:
      - использует: action/setup-node@v3
        с:
          версия узла: ${{ matrix.node }}
      - если: ${{ matrix.npm }}
        выполнить: npm install -g npm@${{ matrix.npm }}
      - запустить: npm --версия

Пример: добавление конфигураций

Например, эта матрица будет запускать 10 заданий, по одному для каждой комбинации os и версии в матрице, а также задание для os со значением windows-latest и версия значение 17 .

 рабочих мест:
  пример_матрицы:
    стратегия:
      матрица:
        os: [macos-последние, windows-последние, ubuntu-последние]
        версия: [12, 14, 16]
        включают:
          - ОС: windows-последняя
            версия: 17

Если вы не укажете какие-либо матричные переменные, все конфигурации под включают . Например, следующий рабочий процесс будет запускать два задания, по одному для каждой записи , включая . Это позволяет вам воспользоваться матричной стратегией, не имея полностью заполненной матрицы.

 рабочих мест:
  include_only:
    запуски: ubuntu-последняя
    стратегия:
      матрица:
        включают:
          - сайт: "производство"
            центр обработки данных: "site-a"
          - сайт: "постановка"
            центр обработки данных: "site-b"

jobs..strategy.matrix.exclude

Чтобы удалить определенные конфигурации, определенные в матрице, используйте jobs. .strategy.matrix.exclude . Исключенная конфигурация должна иметь только частичное совпадение, чтобы ее можно было исключить. Например, следующий рабочий процесс будет выполнять девять заданий: одно задание для каждой из 12 конфигураций, минус одно исключенное задание, соответствующее {os: macos-latest, version: 12, environment: production} , и два исключенных задания. что соответствует {ОС: последняя версия Windows, версия: 16} .

 стратегия:
  матрица:
    os: [macos-последние, windows-последние]
    версия: [12, 14, 16]
    среда: [постановка, производство]
    исключать:
      - os: macos-последняя
        версия: 12
        среда: производство
      - ОС: windows-последняя
        версия: 16
запуски: ${{ matrix.os }}

Примечание: Все включают комбинаций, обрабатываются после исключают . Это позволяет использовать , включая для добавления обратных комбинаций, которые ранее были исключены.

заданий..strategy.fail-fast

Вы можете управлять обработкой сбоев заданий с помощью заданий ..strategy.fail-fast и заданий..continue-on -ошибка .

jobs..strategy.fail-fast применяется ко всей матрице. Если для jobs..strategy.fail-fast установлено значение true , GitHub отменит все выполняемые и поставленные в очередь задания в матрице, если какое-либо задание в матрице завершится неудачно. Это свойство по умолчанию равно верно .

заданий. .continue-on-error относится к одному заданию. Если заданий..continue-on-error равно true , другие задания в матрице будут продолжать выполняться, даже если задание с заданиями..continue-on-error: true завершится ошибкой.

Вы можете использовать задания . .strategy.fail-fast задания и . .continue-on-error вместе. Например, следующий рабочий процесс запустит четыре задания. За каждую работу продолжение при ошибке определяется значением matrix.experimental . Если какое-либо из заданий с ошибкой продолжения : false завершится ошибкой, все задания, которые выполняются или находятся в очереди, будут отменены. Если задание с continue-on-error: true завершится ошибкой, это не повлияет на другие задания.

 рабочих мест:
  тест:
    запуски: ubuntu-последняя
    продолжение при ошибке: ${{ matrix.experimental }}
    стратегия:
      безотказный: правда
      матрица:
        версия: [6, 7, 8]
        экспериментальный: [ложь]
        включают:
          - версия: 9экспериментальный: правда

заданий..strategy.max-parallel

По умолчанию GitHub максимизирует количество заданий, выполняемых параллельно, в зависимости от доступности исполнителя. Чтобы установить максимальное количество заданий, которые могут выполняться одновременно при использовании стратегии заданий Matrix , используйте заданий. .strategy.max-parallel .

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

 вакансии:
  пример_матрицы:
    стратегия:
      макс-параллельно: 2
      матрица:
        версия: [10, 12, 14]
        ОС: [ubuntu-последняя, Windows-последняя]

jobs..continue-on-error

Предотвращает сбой рабочего процесса при сбое задания. Установите значение true , чтобы разрешить выполнение рабочего процесса в случае сбоя этого задания.

Пример: Предотвращение сбоя запуска рабочего процесса для определенного задания матрицы сбоев

Можно разрешить сбой определенных заданий в матрице заданий без сбоя выполнения рабочего процесса. Например, если вы хотите разрешить экспериментальное задание только с 9Узел 0816 установлен на 15 для отказа без сбоя выполнения рабочего процесса.

 запуски: ${{ matrix.os }}
продолжение при ошибке: ${{ matrix.experimental }}
стратегия:
  отказоустойчивость: ложь
  матрица:
    узел: [13, 14]
    os: [macos-последняя, ubuntu-последняя]
    экспериментальный: [ложь]
    включают:
      - узел: 15
        ОС: ubuntu-последняя
        экспериментальный: правда

jobs..container

Примечание. Если в ваших рабочих процессах используются действия контейнера Docker, контейнеры заданий или контейнеры служб, вы должны использовать средство запуска Linux:

Если вы используете средства выполнения, размещенные на GitHub, вы должны использовать средство выполнения Ubuntu.
Если вы используете собственные средства выполнения, вы должны использовать компьютер с Linux в качестве средства выполнения и должен быть установлен Docker.

Используйте задания ..container для создания контейнера для выполнения любых шагов задания, для которых контейнер еще не указан. Если у вас есть шаги, в которых используются действия сценария и контейнера, действия контейнера будут выполняться как одноуровневые контейнеры в той же сети с теми же подключениями тома.

Если вы не установите контейнер , все шаги будут выполняться непосредственно на хосте, указанном параметром run-on , если только шаг не относится к действию, настроенному для выполнения в контейнере.

Примечание: Оболочка по умолчанию для запуска шагов внутри контейнера — sh вместо bash . Это можно переопределить с помощью заданий . .defaults.run или заданий..steps[*].shell .

Пример: выполнение задания в контейнере

При указании только образа контейнера ключевое слово image можно опустить.

 рабочих мест:
  контейнер-тест-задание:
    запуски: ubuntu-последняя
    контейнер: узел: 14.16

jobs. .container.image

Используйте jobs..container.image , чтобы определить образ Docker, который будет использоваться в качестве контейнера для выполнения действия. Значение может быть именем образа Docker Hub или именем реестра.

job..container.credentials

Если реестр контейнеров образа требует проверки подлинности для извлечения образа, вы можете использовать задания ..container.credentials , чтобы установить карту имени пользователя и пароля . Учетные данные — это те же значения, которые вы бы предоставили команде docker login .

Пример: определение учетных данных для реестра контейнеров

 контейнер:
  изображение: ghcr.io/владелец/изображение
  реквизиты для входа:
     имя пользователя: ${{github.actor}}
     пароль: ${{ secrets.github_token }}

jobs..container.env

Используйте jobs. .container.env , чтобы установить карту переменных среды в контейнере.

jobs..container.ports

Используйте jobs..container.ports , чтобы задать массив портов, которые будут отображаться в контейнере.

заданий..container.volumes

Использовать заданий..container.volumes , чтобы установить массив томов для использования контейнером. Тома можно использовать для обмена данными между службами или другими этапами задания. Вы можете указать именованные тома Docker, анонимные тома Docker или привязать монтирование к хосту.

Чтобы указать том, укажите исходный и целевой пути:

<источник>:<путь_назначения> .

— это имя тома или абсолютный путь на хост-компьютере, а — это абсолютный путь в контейнере.

Пример: монтирование томов в контейнер

 томов:
  - my_docker_volume:/volume_mount
  - /данные/мои_данные
  - /источник/каталог:/пункт назначения/каталог

jobs. .container.options

Используйте jobs..container.options для настройки дополнительных параметров ресурсов контейнера Docker. Список параметров см. в разделе « docker create options».

Предупреждение: Параметр --network не поддерживается.

jobs..services

Примечание. Если ваши рабочие процессы используют действия контейнера Docker, контейнеры заданий или контейнеры служб, вы должны использовать средство запуска Linux:

Если вы используете GitHub-hosted бегунов, вы должны использовать бегун Ubuntu.
Если вы используете собственные средства выполнения, вы должны использовать компьютер с Linux в качестве средства выполнения и должен быть установлен Docker.

Используется для размещения сервисных контейнеров для задания в рабочем процессе. Контейнеры служб полезны для создания баз данных или служб кэширования, таких как Redis. Средство выполнения автоматически создает сеть Docker и управляет жизненным циклом сервисных контейнеров.

Если вы настроили задание для запуска в контейнере или на вашем шаге используются действия контейнера, вам не нужно сопоставлять порты для доступа к службе или действию. Docker автоматически предоставляет все порты между контейнерами в одной и той же пользовательской мостовой сети Docker. Вы можете напрямую ссылаться на сервисный контейнер по его имени хоста. Имя хоста автоматически сопоставляется с именем метки, которое вы настраиваете для службы в рабочем процессе.

Если вы настроили задание для запуска непосредственно на компьютере исполнителя и ваш шаг не использует действие контейнера, вы должны сопоставить все необходимые порты контейнера службы Docker с хостом Docker (машиной исполнителя). Вы можете получить доступ к контейнеру службы, используя localhost и сопоставленный порт.

Дополнительные сведения о различиях между контейнерами сетевых служб см. в разделе «О контейнерах служб».

Пример: использование localhost

В этом примере создаются две службы: nginx и redis. Когда вы указываете порт хоста Docker, но не порт контейнера, порт контейнера случайным образом назначается свободному порту. GitHub устанавливает назначенный порт контейнера в ${{job.services..ports}} контекст. В этом примере вы можете получить доступ к портам контейнера службы, используя ${{ job.services.nginx.ports['8080'] }} и ${{ job.services.redis.ports['6379'] } } контекстов.

 услуги:
  нгинкс:
    изображение: nginx
    # Сопоставить порт 8080 на хосте Docker с портом 80 на контейнере nginx
    порты:
      - 8080:80
  редис:
    изображение: редис
    # Сопоставьте TCP-порт 6379 на хосте Docker со случайным свободным портом в контейнере Redis
    порты:
      - 6379/ TCP

jobs..services..image

Образ Docker для использования в качестве контейнера службы для запуска действия. Значение может быть именем образа Docker Hub или именем реестра.

jobs..services..credentials

Если реестр контейнеров образа требует аутентификации для извлечения образа, вы можете использовать jobs..container.credentials , чтобы установить карту из имя пользователя и пароль . Учетные данные — это те же значения, которые вы бы предоставили команде docker login .

Пример

 услуги:
  мойсервис1:
    изображение: ghcr.io/owner/myservice1
    реквизиты для входа:
      имя пользователя: ${{github.actor}}
      пароль: ${{ secrets.github_token }}
  мойсервис2:
    изображение: dockerhub_org/myservice2
    реквизиты для входа:
      имя пользователя: ${{ secrets.DOCKER_USER }}
      пароль: ${{ secrets.DOCKER_PASSWORD }}

jobs..services..env

Задает карту переменных среды в контейнере службы.

jobs..services..ports

Устанавливает массив портов для предоставления в сервисном контейнере.

jobs..services..volumes

Задает массив томов для использования сервисным контейнером. Тома можно использовать для обмена данными между службами или другими этапами задания. Вы можете указать именованные тома Docker, анонимные тома Docker или привязать монтирование к хосту.

Чтобы указать том, укажите исходный и целевой пути:

<источник>:<путь_назначения> .

— это имя тома или абсолютный путь на хост-компьютере, а — абсолютный путь в контейнере.

Пример

 томов:
  - my_docker_volume:/volume_mount
  - /данные/мои_данные
  - /источник/каталог:/пункт назначения/каталог

jobs..services..options

Дополнительные параметры ресурсов контейнера Docker. Список параметров см. в разделе « docker create options».

Предупреждение: Параметр --network не поддерживается.

jobs..uses

Местоположение и версия многократно используемого файла рабочего процесса для запуска в качестве задания. Используйте один из следующих синтаксисов:

{owner}/{repo}/.github/workflows/{filename}@{ref} для повторного использования рабочих процессов в общедоступных репозиториях.
./.github/workflows/{filename} для повторного использования рабочих процессов в одном репозитории.

{ref} может быть SHA, тегом выпуска или именем ветки. Использование SHA фиксации является самым безопасным для стабильности и безопасности. Дополнительные сведения см. в разделе «Усиление безопасности для действий GitHub». Если вы используете второй вариант синтаксиса (без {owner}/{repo} и @{ref} ), вызываемый рабочий процесс находится в той же фиксации, что и вызывающий рабочий процесс.

Пример

вакансии: call-workflow-1-in-local-repo: использует: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b2137

a9eb89 call-workflow-2-in-local-repo: использует: ./.github/workflows/workflow-2.yml вызов рабочего процесса в другом репо: использует: octo-org/another-repo/.github/workflows/workflow.yml@v1

Дополнительные сведения см. в разделе «Повторное использование рабочих процессов».

jobs..with

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

Любые входные данные, которые вы передаете, должны соответствовать спецификациям входных данных, определенным в вызываемом рабочем процессе.

В отличие от заданий ..steps[*].with , входные данные, которые вы передаете с заданиями . .with , недоступны в качестве переменных среды в вызываемом рабочем процессе. Вместо этого вы можете ссылаться на входные данные, используя контекст inputs .

Пример

 вакансии:
  рабочий процесс вызова:
    использует: octo-org/example-repo/.github/workflows/call-workflow.yml@main
    с:
      имя пользователя: мона

jobs..with.

Пара, состоящая из строкового идентификатора ввода и значения ввода. Идентификатор должен соответствовать имени входа, определенному on.workflow_call.inputs. в вызываемом рабочем процессе. Тип данных значения должен соответствовать типу, определенному в on.workflow_call.inputs..type 9.0817 в вызываемом рабочем процессе.

Допустимые контексты выражений: github и требуется .

 jobs..secrets  Когда задание используется для вызова повторно используемого рабочего процесса, вы можете использовать  секретов  для предоставления карты секретов, которые передаются вызываемому рабочему процессу.
 Все секреты, которые вы передаете, должны соответствовать именам, определенным в вызываемом рабочем процессе.
 Пример 
 заданий:
  рабочий процесс вызова:
    использует: octo-org/example-repo/.github/workflows/call-workflow.yml@main
    секреты:
      токен доступа: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
 
 jobs..secrets.inherit  Используйте ключевое слово  inherit , чтобы передать все секреты вызывающего рабочего процесса вызываемому рабочему процессу. Сюда входят все секреты, к которым имеет доступ вызывающий рабочий процесс, а именно секреты организации, репозитория и среды. Ключевое слово  наследовать  можно использовать для передачи секретов между репозиториями в одной организации или между организациями в рамках одного предприятия.
 Пример 
 на:
  workflow_dispatch:
вакансии:
  передать секреты в рабочий процесс:
    использует: ./.github/workflows/call-workflow.yml
    секреты: наследовать
 
 по телефону:
  рабочий_вызов:
вакансии:
  передать секрет к действию:
    запуски: ubuntu-последняя
    шаги:
      - имя: используйте секрет репозитория или организации из вызывающего рабочего процесса. 
        запустить: эхо ${{ секреты.CALLING_WORKFLOW_SECRET }}
 
 jobs..secrets.  Пара, состоящая из строкового идентификатора секрета и значения секрета. Идентификатор должен соответствовать имени секрета, определенному в  on.workflow_call.secrets.  в вызываемом рабочем процессе.
 Допустимые контексты выражений:  github  ,  need  и  secrets  .
 Шпаргалка по шаблону фильтра 
 В фильтрах путей, ответвлений и тегов можно использовать специальные символы.

  *  : Соответствует нулю или более символов, но не соответствует символу /. Например,  Octo*  соответствует  Octocat  .
  **  : соответствует нулю или более любых символов.
  ?  : соответствует нулю или одному предшествующему символу.
  +  : Соответствует одному или нескольким предшествующим символам.

[] Соответствует одному символу, указанному в скобках или включенному в диапазоны. Диапазоны могут включать только a-z , A-Z и 0-9 . Например, диапазон [0-9a-z] соответствует любой цифре или строчной букве. Например, [CB]at соответствует Cat или Bat и 9.0816 [1-2]00 соответствует 100 и 200 .
! : В начале паттерна отрицает предыдущие положительные паттерны. В нем нет особого смысла, если не первый символ.

Символы * , [ и ! — это специальные символы в YAML. Если вы начинаете шаблон с * , [ или ! шаблон необходимо заключить в кавычки. Кроме того, если вы используете последовательность потоков с шаблоном, содержащим [ и/или ] шаблон должен быть заключен в кавычки.

 # Действительно
ветви:
  - '**/README.md'
# Invalid - создает ошибку синтаксического анализа, которая
# предотвращает запуск вашего рабочего процесса.
ветви:
  - **/README.md
# Действительный
ветки: [основная, 'выпуск/v[0-9].[0-9]']
# Invalid - создает ошибку синтаксического анализа
ветки: [основная, выпуск/v[0-9].[0-9]]

Для получения дополнительной информации о синтаксисе ветвей, тегов и фильтров путей см. " on.. ", " on.. ", и" ON. Подстановочный знак * соответствует любому символу, но не соответствует косой черте ( / ).0816 feature/** Подстановочный знак ** соответствует любому символу, включая косую черту ( / ) в именах ветвей и тегов. feature/beta-a/my-branch

feature/your-branch

feature/mona/the/octocat

main

releases/mona-the-octocat

Соответствует точному имени ветви или имени тега.

основной

релизы/mona-the-octocat

'*' Соответствует всем именам ветвей и тегов, которые не содержат косую черту ( / ). Символ * — это специальный символ в YAML. Когда вы начинаете шаблон с * , вы должны использовать кавычки. основной

релизы

'**' Соответствует всем именам ветвей и тегов. Это поведение по умолчанию, когда вы не используете ветки

 9.0817 или  теги  фильтр.  все/ветки   каждый/тег 
  '*feature'   *  символ в YAML. Когда вы начинаете шаблон с  * , вы должны использовать кавычки.  Mona-Feature   Функция 
  Ver-10-Feeture 
  V2*  MATCHES MATCHES и TAGATES MATCHES и Tag. 0816 v2

. V2

V2.0

V2.9

 V [12]. и теги с основной версией 1 или 2.  v1.10.1   v2.0.0 
 Шаблоны для сопоставления путей к файлам 
 92 Файл с файлом0816 .md  суффикс в любом месте каталога  docs . Шаблон  Описание совпадений  Пример совпадений
  '*'  Подстановочный знак  *  /  8s не соответствует ни одному символу, но не соответствует ни одному символу. Символ  *  — это специальный символ в YAML. Когда вы начинаете шаблон с  * , вы должны использовать кавычки.   README.md   server.rb 
  '*.jsx?'   ? Символ  соответствует нулю или одному из предшествующих символов.   Page.js   Page. jsx 
  '**' . Это поведение по умолчанию, если вы не используете фильтр пути  .   all/the/files.md 
  '*.js'  9Подстановочный знак 0816 *  соответствует любому символу, но не соответствует косой черте (  /  ). Соответствует всем  файлам .js  в корне репозитория.   app.js   index.js 
  '**.js'  Соответствует всем  файлам .17 в репозитории 90   index.js   js/index.js 
  src/js/app.js 
  docs*1  Все файлы в корне каталога  docs  в корне репозитория.   docs/README.md   docs/file.txt 
  docs/**  в корневом каталоге репозитория 96 / 90docs1   docs/README. md   docs/mona/octocat.txt 
  docs/**/*.md   docs/README.md   docs/mona/hello-world.md 
  docs/a/markdown/file.md 
  '**/docs/**'  Любые файлы в каталоге  docs  в любом месте репозитория.   docs/hello.md   dir/docs/my-file.txt 
  space/docs/plan/space.doc 
  '**/README.md'  Файл README.md в любом месте репозитория.   readme.md   JS/README.MD 
  '**/*SRC/** 8888888 гг.   a/src/app.js   my-src/code/js/app.js 
  '**/*-post.md'  92 Файл с расширением0816 -post. md  в любом месте репозитория.   MY-POST.MD   PATH/IHOR-POST.MD 
  '**/MIGRATE-*. SQL' 8888888 AILIX с Prefix  588888888 A.ILIX
108108.IIL-8.IIL-8.IIL-8.IIX  '**/MIGRATE-*. .sql  в любом месте репозитория.   migrate-10909.sql   db/migrate-v1.0.sql 
  db/sept/migrate-v1.sql 
  *.md   !README.md  Использование восклицательного знака (  !  ) перед шаблоном отменяет его. Если файл соответствует шаблону, а также соответствует отрицательному шаблону, определенному в файле позже, файл не будет включен.   hello.md   Does not match 
  README.md 
  docs/hello.md 
  *.md   !README. md 
  README *  Шаблоны проверяются последовательно. Шаблон, отрицающий предыдущий шаблон, будет повторно включать пути к файлам.   hello.md   README.md 
  README.doc 
 ключевое слово `.gitlab`yml-ci. GitLab 
 Ключевые слова
 Глобальные ключевые слова  по умолчанию 
  включает   включает: местный 
  включает: файл 
  включает: удаленный 
  включает: шаблон 
  этапы 
  рабочий процесс   рабочий процесс:правила 
  рабочий процесс:правила:переменные 
 Ключевые слова работы  after_script 
  allow_failure   allow_failure:exit_codes 
  artifacts   artifacts:paths 
  artifacts:exclude 
  artifacts:expire_in 
  artifacts:expose_as 
  artifacts:name 
  artifacts:public 
  artifacts: отчеты 
  артефакты: неотслеживаемые 
  артефакты: когда 
  before_script 
  кэш   кэш: пути 
  Кэш: ключ   Кэш: Ключ: Файлы 
  Кэш: Ключ: Префикс 
  Кэш: 
  CACHE: 
  CACHACE: 
 16 CACHECHE: 
6161616 CACHES  покрытие 
  dast_configuration 
  зависимости 
  окружающая среда   environment:name 
  environment:url 
  environment:on_stop 
  environment:action 
  environment:auto_stop_in 
  environment:kubernetes 
  environment:deployment_tier 
 Динамические среды
  расширяет 
  изображение   изображение:имя 
  изображение: точка входа 
  изображение: pull_policy 
  наследовать   наследовать: по умолчанию 
  наследовать: переменные 
  прерываемый 
  Нужен   Потребности: Артефакты 
  Потребности: Проект 
  Потребности: Трубопровод: работа 
 . 0817
  Только  /, кроме   только: refs  /, за исключением: refs 
  только: переменные  / За исключением: переменные 
  /, за исключением: переменные   /: переменные  /. :kubernetes  /  кроме:kubernetes 
  страницы 
  параллельный   параллельный:матричный 
  Выпуск   Выпуск: TAG_NAME 
  Выпуск: TAG_MESSAGE 
  Выпуск. 
 . Релиз: Описание 
 7. Release_at 
  выпуск:активы:ссылки 
  группа_ресурсов 
  повторить   повтор: когда 
  правил   правил: если 
  Правила: Изменения   Правила: Изменения: Путь 
  Правила: Изменения: Compare_TO 
  Правила: существует 
  Правила: Allow_FALURE 
 .  сценарий 
  секретов   секретов: хранилище 
  секреты: файл 
  сервисы   сервис:pull_policy 
  этап   этап: .pre 
  этап: .post 
  теги 
 9016
07  выход  триггер   триггер:включить 
  триггер:проект 
  триггер:стратегия 
  триггер: вперед 
  переменных   переменных:описание 
  когда 
 Установленные ключевые слова Глобально определенные  Изображение ,  Сервисы ,  Кэш ,  перед_SCRICT ,  Последующий документ 
. файл 0817.
 Для быстрого ознакомления с GitLab CI/CD следуйте краткому руководству.
 Набор примеров см. в GitLab CI/CD Examples.
 Чтобы просмотреть большой файл  .gitlab-ci.yml , используемый на предприятии, см. файл  .gitlab-ci.yml  для  gitlab  .
 Когда вы редактируете файл  .gitlab-ci.yml , вы можете проверить его с помощью
Инструмент CI Lint.
 Если вы редактируете содержимое этой страницы, следуйте инструкциям по документированию ключевых слов.
 Ключевые слова 
 Конфигурация конвейера GitLab CI/CD включает:
 Глобальные ключевые слова, которые настраивают поведение конвейера:
 Ключевое слово  Описание
  default  Пользовательские значения по умолчанию для заданий.
  include  Импорт конфигурации из других файлов YAML.
  ступени  Названия и порядок этапов конвейера.
  переменные  Определите переменные CI/CD для всех заданий в конвейере.
  рабочий процесс  Управление типами конвейера.
 Задания, сконфигурированные с ключевыми словами задания:
 Ключевое слово  Описание
  after_script  Переопределяют набор команд, выполняемых после задания.
  allow_failure  Разрешить сбой задания. Неудачное задание не приводит к сбою конвейера.
  артефакты  Список файлов и каталогов, которые необходимо прикрепить к заданию в случае успеха.
  before_script  Переопределить набор команд, которые выполняются перед заданием.
  кэш  Список файлов, которые следует кэшировать между последующими запусками.
  покрытие  Параметры покрытия кода для данного задания.
  dast_configuration  Использовать конфигурацию из профилей DAST на уровне задания.
  зависимости  Ограничьте передачу артефактов конкретному заданию, предоставив список заданий, из которых нужно получить артефакты.
  среда  Имя среды, в которой развертывается задание.
  кроме  Управление, когда задания не создаются.
  extends  Записи конфигурации, от которых наследуется это задание.
  образ  Используйте образы Docker.
  наследовать  Выберите, какие глобальные значения по умолчанию наследуют все задания.
  прерываемый  Определяет, может ли задание быть отменено, если оно становится избыточным при новом запуске.
  потребности  Выполнение работ до стадии заказа.
  только  Управление созданием заданий.
  страниц  Загрузите результат задания для использования с GitLab Pages.
  параллельно  Сколько экземпляров задания должно выполняться параллельно.
  выпуск  Указывает бегуну создать объект выпуска.
  группа_ресурсов  Ограничение одновременности заданий.
  повтор  Когда и сколько раз задание может быть автоматически повторено в случае сбоя.
  правила  Список условий для оценки и определения выбранных атрибутов задания, а также того, создано оно или нет.
  сценарий  Сценарий оболочки, который выполняется бегуном.
  секреты  Секреты CI/CD необходимы для работы.
  services  Используйте образы служб Docker.
  этап  Определяет этап задания.
  теги  Список тегов, которые используются для выбора бегуна.
  время ожидания  Определите пользовательское время ожидания на уровне задания, которое имеет приоритет над настройкой всего проекта.
  триггер  Определяет триггер нисходящего конвейера.
  переменные  Определите переменные задания на уровне задания.
  когда  Когда запускать задание.
 Глобальные ключевые слова 
 Некоторые ключевые слова не определены в задании. Эти ключевые слова управляют поведением конвейера.
или импортировать дополнительную конфигурацию конвейера.
 по умолчанию  Для некоторых ключевых слов можно установить глобальные значения по умолчанию. Задания, не определяющие один или несколько
перечисленных ключевых слов используют значение, определенное в разделе  по умолчанию .
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входные данные : эти ключевые слова могут иметь пользовательские дефолты:
  weps_script 
  Артефакты 
  Перед_ 
 7.0816 image 
  interruptible 
  retry 
  services 
  tags 
  timeout 
  Example of  default   :
 default:
  изображение: рубин: 3. 0
rspec:
  скрипт: пакет exec rspec
рспец 2.7:
  изображение: рубин: 2,7
  скрипт: пакет exec rspec
 
 В этом примере  ruby:3.0  — это значение  image  по умолчанию для всех заданий в конвейере.  rspec 2.7  задание не использует значение по умолчанию, поскольку оно переопределяет значение по умолчанию с помощью
изображение  для конкретного задания  section:
  Дополнительные сведения  :
 При создании конвейера каждое значение по умолчанию копируется во все задания, которые не имеют
это ключевое слово определено.
 Если для задания уже настроено одно из ключевых слов, конфигурация в задании
имеет приоритет и не заменяется значением по умолчанию.
 Управление наследованием ключевых слов по умолчанию в заданиях с  наследовать: по умолчанию .
 включает  Перемещено в GitLab Free в версии 11.4.
 Используйте  include  для включения внешних файлов YAML в конфигурацию CI/CD. Вы можете разделить один длинный файл  .gitlab-ci.yml  на несколько файлов, чтобы улучшить читаемость,
или уменьшить дублирование одной и той же конфигурации в нескольких местах.
 Вы также можете хранить файлы шаблонов в центральном репозитории и включать их в проекты.
  включают файлы :
 Объединены с файлами  .gitlab-ci.yml .
 Всегда сначала оценивается, а затем объединяется с содержимым файла  .gitlab-ci.yml ,
независимо от позиции  включите ключевое слово .
 Можно вложить до 100 включений. В GitLab 14.9 и более поздних версиях
один и тот же файл может быть включен несколько раз во вложенные включения, но дубликаты игнорируются.
 В GitLab 12.4 и более поздних версиях
ограничение по времени для разрешения всех файлов составляет 30 секунд.
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входные данные :  включает в себя  подказки:
  Включите: Local 
  Включите: File 
  Включите: RELOTE 
 66698.  . Используйте слияние для настройки и переопределения включенных конфигураций CI/CD с локальными Вы можете переопределить включенную конфигурацию, используя то же имя задания или глобальное ключевое слово
в  .gitlab-ci.yml  файл. Две конфигурации объединяются вместе, и
конфигурация в файле  .gitlab-ci.yml  имеет приоритет над включенной конфигурацией.
 Если вы повторно запустите: Задание,  include  файлы не загружаются снова. Все задания в конвейере используют конфигурацию
извлекается при создании конвейера. Любые изменения исходного кода  включают файлы .
не влияют на повторные запуски заданий.
 Конвейер,  include  файлов извлекаются снова. Если они изменились после последней
запуск конвейера, новый конвейер использует измененную конфигурацию.
  Похожие темы  :
 Используйте переменные с , включая .
 Используйте  правил  с  включите  .
 включает: местный  Используйте  include:local  для включения файла, находящегося в том же репозитории, что и файл  .gitlab-ci.yml .
Используйте  include:local  вместо символических ссылок.
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входные данные  :
 Полный путь относительно корневого каталога (  /  ):
 Файл YAML должен иметь расширение  .yml  или  .yaml  .
 Вы можете использовать подстановочные знаки  *  и  **  в пути к файлу.
 Вы можете использовать определенные переменные CI/CD.
  Пример  включает: местный   :
 включает:
  - локальный: '/templates/.gitlab-ci-template.yml'
 
 Вы также можете использовать более короткий синтаксис для определения пути:
 include: '. gitlab-ci-production.yml'
 
  Дополнительные сведения  :
 Файл  .gitlab-ci.yml  и локальный файл должны находиться в одной ветке.
 Вы не можете включать локальные файлы через пути подмодулей Git.
 Все вложенные включения выполняются в рамках одного проекта,
поэтому вы можете использовать локальные, проектные, удаленные или шаблонные включения.
 включает: файл  Включая несколько файлов из одного проекта, представленного в GitLab 13.6. Флаг функции удален в GitLab 13.8.
 Чтобы включить файлы из другого частного проекта в тот же экземпляр GitLab,
используйте  include:file  . Вы можете использовать  include:file  в сочетании с  include:project  только.
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные значения  :
 Полный путь относительно корневого каталога (  /  ):
 Файл YAML должен иметь расширение  . yml  или  .yaml  .
 Вы можете использовать определенные переменные CI/CD.
  Пример  include:file   :
 include:
  - проект: 'моя группа/мой проект'
    файл: '/templates/.gitlab-ci-template.yml'
 
 Вы также можете указать  ref  . Если вы не укажете значение, ссылка по умолчанию будет  HEAD  проекта:
 включает:
  - проект: 'моя группа/мой проект'
    ссылка: основной
    файл: '/templates/.gitlab-ci-template.yml'
  - проект: 'моя группа/мой проект'
    ссылка: v1.0.0 # Тег Git
    файл: '/templates/.gitlab-ci-template.yml'
  - проект: 'моя группа/мой проект'
    ссылка: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA
    файл: '/templates/.gitlab-ci-template.yml'
 
 Вы можете включить несколько файлов из одного проекта:
 включает:
  - проект: 'моя группа/мой проект'
    ссылка: основной
    файл:
      - '/templates/.builds.yml'
      - '/templates/. tests.yml'
 
  Дополнительные сведения  :
 Все вложенные включения выполняются в рамках целевого проекта.
Можно использовать  локальный  (относительно целевого проекта),  проект ,  удаленный  или  шаблон  включает.
 При запуске конвейера оценивается конфигурация файла  .gitlab-ci.yml , включенная всеми методами.
Конфигурация представляет собой снимок во времени и сохраняется в базе данных. GitLab не отражает никаких изменений в
указанную конфигурацию файла  .gitlab-ci.yml  до запуска следующего конвейера.
 При включении файла YAML из другого частного проекта пользователь, запускающий конвейер
должен быть участником обоих проектов и иметь соответствующие разрешения для запуска конвейеров.
А  не найден или доступ запрещен Ошибка  может отображаться, если у пользователя нет доступа ни к одному из включенных файлов.
 включает: удаленный  Используйте  include:remote  с полным URL-адресом, чтобы включить файл из другого места.
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входные данные  :
 Общедоступный URL-адрес, доступный по запросу HTTP/HTTPS  GET :
 Аутентификация с удаленным URL-адресом не поддерживается.
 Файл YAML должен иметь расширение  .yml  или  .yaml  .
 Вы можете использовать определенные переменные CI/CD.
  Пример  включает: удаленный   :
 включает:
  - удаленный: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
 
  Дополнительные сведения  :
 Все вложенные включения выполняются без контекста в качестве общедоступного пользователя,
поэтому вы можете включать только общедоступные проекты или шаблоны.
 Будьте осторожны при включении удаленного файла конфигурации CI/CD. Никаких конвейеров или уведомлений
срабатывает при изменении внешних файлов конфигурации CI/CD. С точки зрения безопасности,
это похоже на получение сторонней зависимости.
 включает: шаблон  Используйте  include:template  для включения шаблонов  .gitlab-ci.yml .
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входы  :
 Шаблон CI/CD:
 Шаблоны хранятся в  lib/gitlab/ci/templates  .
Не все шаблоны предназначены для использования с  include:template  , поэтому проверьте шаблон
комментарии перед использованием.
 Вы можете использовать определенные переменные CI/CD.
  Пример  include:template   :
 # Файл получен из коллекции шаблонов GitLab
включают:
  - шаблон: Auto-DevOps.gitlab-ci.yml
 
 Несколько  include:template  файлы:
 включает:
  - шаблон: Android-Fastlane.gitlab-ci.yml
  - шаблон: Auto-DevOps.gitlab-ci. yml
 
  Дополнительные сведения  :
 Все вложенные включения выполняются только с разрешения пользователя,
так что можно использовать  проект ,  удаленный  или  шаблон  включает.
 этапов  Используйте этапы   для определения этапов, содержащих группы заданий. Используйте  этап  в задании, чтобы настроить выполнение задания на определенном этапе.
 Если  Стадии  не определены в файле  .Gitlab-Ci.yml , стадии трубопровода по умолчанию:
 . PRE 
  Build 
   Build 
   
   
 
  
 
   9000 
   9000 
  .
  .post 
 Порядок элементов на  этапах  определяет порядок выполнения заданий:
 Задания на одном этапе выполняются параллельно.
 Задания следующего этапа запускаются после успешного завершения заданий предыдущего этапа.
 Если конвейер содержит только задания на этапах  .pre  или  .post , он не запускается.
На другом этапе должна быть хотя бы одна другая работа.  .до  и  .после  этапов
может использоваться в требуемой конфигурации конвейера
для определения заданий соответствия, которые должны выполняться до или после заданий конвейера проекта.
  Тип ключевого слова  : Глобальное ключевое слово.
  Пример  ступеней   :
 ступени:
  - строить
  - тест
  - развертывать
 
 В этом примере:
 Все задания в  сборке  выполняются параллельно.
 Если все задания в  сборке  выполнены успешно, тестовые задания   выполняются параллельно.
 Если все задания в  тестируют  успешно, задания  по развертыванию  выполняются параллельно.
 Если все задания в  развертывании  выполнены успешно, конвейер помечается как  переданный  .
 В случае сбоя какого-либо задания конвейер помечается как  failed , а задания на более поздних этапах не выполняются.
Начало. Задания на текущем этапе не останавливаются и продолжают выполняться.
  Дополнительные сведения  :
 Если в задании не указан этап   , заданию назначается этап  test .
 Если этап определен, но ни одно задание не использует его, этап не отображается в конвейере,
которые могут помочь конфигурациям конвейера соответствия: Этапы можно определить в конфигурации соответствия, но они остаются скрытыми, если не используются.
 Определенные этапы становятся видимыми, когда разработчики используют их в определениях заданий.
  Связанные темы  :
 Чтобы запустить задание раньше и игнорировать порядок этапов, используйте ключевое слово  need .
 рабочий процесс  Представлено в GitLab 12.5
 Используйте рабочий процесс   для управления поведением конвейера.
  Связанные темы  :
  рабочий процесс: правила  примеры
 Переключение между ответвленными конвейерами и конвейерами мерж-реквестов
 Рабочий процесс 
: правила  Ключевое слово  rules  в рабочем процессе   аналогично правилам  , определенным в заданиях,
но контролирует, будет ли создан весь конвейер.
 Если ни одно из правил не оценивается как истинное, конвейер не запускается.
  Возможные входные данные  : Вы можете использовать некоторые из тех же ключевых слов, что и правила уровня задания   :
 Правила : если  .
  правил: изменения  .
  правил: существует  .
  вместо  может быть только  всегда  или  никогда не  при использовании с рабочим процессом   .
  переменных  .
  Пример рабочего процесса : правила   :
 рабочего процесса:
  правила:
    - если: $CI_COMMIT_TITLE =~ /-черновик$/
      когда: никогда
    - если: $CI_PIPELINE_SOURCE == "merge_request_event"
    - если: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
 
 В этом примере конвейеры запускаются, если заголовок фиксации (первая строка сообщения фиксации) не заканчивается на  -черновик  и конвейер для:
 Мерж-реквест
 Ветка по умолчанию.
  Дополнительные сведения  :
 Если ваши правила соответствуют как конвейерам ответвлений (кроме ответвления по умолчанию), так и конвейерам мерж-реквестов,
могут возникать дублирующие конвейеры.
  Связанные темы  :
 Вы можете использовать шаблоны  workflow:rules  для импорта
предварительно настроенный рабочий процесс : правила 9запись 0817.
 Общие пункты  if  для рабочего процесса : правила  .
 Используйте правила   для запуска конвейеров мерж-реквестов.
 рабочий процесс:правила:переменные  История версий
 Представлено в GitLab 13.11.
 Флаг функции удален в GitLab 14.1.
 Вы можете использовать переменные   в рабочем процессе : правила  для определения переменных для
конкретные условия трубопровода.
 При совпадении условия переменная создается и может использоваться всеми заданиями
в трубопроводе. Если переменная уже определена на глобальном уровне, рабочий процесс   переменная имеет приоритет и переопределяет глобальную переменную.
  Тип ключевого слова  : Глобальное ключевое слово.
  Возможные входные данные  : Пары имени и значения переменной:
 Имя может использовать только цифры, буквы и знаки подчеркивания (  _  ).
 Значение должно быть строкой.
  Пример  рабочий процесс:правила:переменные   :
 переменные:
  DEPLOY_VARIABLE: «развертывание по умолчанию»
рабочий процесс:
  правила:
    - если: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      переменные:
        DEPLOY_VARIABLE: "deploy-production" # Переопределить глобально определенную DEPLOY_VARIABLE
    - если: $CI_COMMIT_REF_NAME =~ /feature/
      переменные:
        IS_A_FEATURE: "true" # Определить новую переменную.
    - when: всегда # Запускать конвейер в остальных случаях
задание1:
  переменные:
    DEPLOY_VARIABLE: "задание1-развертывание по умолчанию"
  правила:
    - если: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      переменные: # Переопределить DEPLOY_VARIABLE определено
        DEPLOY_VARIABLE: "job1-deploy-production" # на уровне задания.
    - when: on_success # Запускать задание в остальных случаях
  сценарий:
    - echo "Запустить скрипт с $DEPLOY_VARIABLE в качестве аргумента"
    - echo "Запустить другой скрипт, если $IS_A_FEATURE существует"
задание2:
  сценарий:
    - echo "Запустить скрипт с $DEPLOY_VARIABLE в качестве аргумента"
    - echo "Запустить другой скрипт, если $IS_A_FEATURE существует"
 
 Если ветвь является ветвью по умолчанию:
 job1’s  DEPLOY_VARIABLE  is  job1-deploy-production  .
 job2  DEPLOY_VARIABLE  — это  deploy-production  .
 Когда ветвь  feature  : job1  DEPLOY_VARIABLE  равно  job1-default-deploy  , а  IS_A_FEATURE  true .
 job2  DEPLOY_VARIABLE  равно  default-deploy  и  IS_A_FEATURE  равно  true  .
 Когда ветвь является чем-то другим:
 job1’s  DEPLOY_VARIABLE  равно  job1-default-deploy  .
 job2  DEPLOY_VARIABLE  равно  default-deploy  .
 Ключевые слова работы 
 В следующих разделах объясняется, как использовать ключевые слова для настройки конвейеров CI/CD.
 после_скрипта  Использование  after_script  для определения массива команд, которые запускаются после каждого задания, включая невыполненные задания.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : Массив, включающий:
 Однострочные команды.
 Длинные команды разбиты на несколько строк.
 Якоря YAML.
 Поддерживаются переменные CI/CD.
  Пример  after_script   :
 задание:
  сценарий:
    - echo "Пример раздела скрипта."
  после_скрипта:
    - echo "Выполните эту команду после завершения раздела `script`."
 
  Дополнительные сведения  :
 Сценарии, указанные вами в  after_script , выполняются в новой оболочке, отдельно от любой  команды before_script  или  script . В результате они:
 Возвращают текущий рабочий каталог к значению по умолчанию (в соответствии с переменными, которые определяют, как бегун обрабатывает запросы Git).
 Нет доступа к изменениям, выполненным командами, определенными в сценарии  before_script  или   ,
включая: Псевдонимы команд и переменные, экспортированные в сценарии   сценариев.
 Изменения вне рабочего дерева (в зависимости от исполнителя раннера), например
программное обеспечение, установленное сценарием  before_script  или  script .
 Есть отдельный тайм-аут, жестко заданный на 5 минут.
 Не влияйте на код выхода задания. Если  script  раздел завершается успешно, и  after_script  истекает по времени или завершается с ошибкой, задание завершается с кодом  0  (  Задание выполнено успешно  ).
 Если время ожидания задания истекло или оно было отменено, команды  after_script  не выполняются.
Существует проблема, связанная с добавлением поддержки выполнения команд  after_script  для заданий с истекшим временем ожидания или отмененных.
  Похожие темы  :
 Используйте  after_script  с  по умолчанию  чтобы определить набор команд по умолчанию, которые должны выполняться после всех заданий.
 Вы можете игнорировать ненулевые коды выхода.
 Используйте цветовые коды с  after_script  для облегчения просмотра журналов заданий.
 Создание настраиваемых складных разделов
для упрощения вывода журнала заданий.
 разрешить_сбой  Используйте  allow_failure , чтобы определить, должен ли конвейер продолжать работу в случае сбоя задания.
 Чтобы конвейер продолжал выполнять последующие задания, используйте  allow_failure: правда  .
 Чтобы остановить выполнение конвейером последующих заданий, используйте  allow_failure: false  .
 Когда задания могут завершаться сбоем (  allow_failure: true  ) оранжевое предупреждение ()
указывает, что задание не выполнено. Однако конвейер выполнен успешно, и соответствующая фиксация
помечается как пройденный без предупреждений.
 Это же предупреждение отображается, когда:
 Все остальные задания на этапе выполнены успешно.
 Все остальные задания в конвейере выполнены успешно.
 Значение по умолчанию для  allow_failure :
  true  для ручных работ.
  false  для заданий, использующих , когда: вручную  внутри  правил  .
  ложь  во всех остальных случаях.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  истина  или  ложь  .
  Пример  allow_failure   :
 job1:
  этап: тест
  сценарий:
    - выполнить_скрипт_1
задание2:
  этап: тест
  сценарий:
    - выполнить_скрипт_2
  allow_failure: правда
задание3:
  этап: развертывание
  сценарий:
    - развертывание_в_постановке
  среда: постановка
 
 В этом примере  задание 1  и  задание 2  выполняются параллельно:
 Если  задание2  завершается сбоем, задания на этапе  развертывания  все еще могут запускаться.
  Дополнительные сведения  :
 Вы можете использовать  allow_failure  в качестве подраздела  правил  .
 Вы можете использовать  allow_failure: false  с ручным заданием, чтобы создать блокирующее ручное задание.
Заблокированный конвейер не запускает никаких заданий на более поздних этапах до тех пор, пока не будет выполнено ручное задание.
запускается и успешно завершается.
 allow_failure:exit_codes  История версий
 Представлено в GitLab 13.8.
 Флаг функции удален в GitLab 13.9.
 Используйте  allow_failure:exit_codes , чтобы контролировать, когда задание должно быть
позволено потерпеть неудачу. Задание  allow_failure: true  для любого из перечисленных кодов выхода,
и  allow_failure  false для любого другого кода выхода.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Один код выхода.
 Массив кодов выхода.
  Пример  allow_failure   :
 test_job_1:
  сценарий:
    - echo "Запустите сценарий, который приведет к коду выхода 1. Это задание не выполнено."
    - выход 1
  разрешить_сбой:
    выход_коды: 137
test_job_2:
  сценарий:
    - echo "Запустите сценарий, который приведет к коду выхода 137. Это задание может завершиться ошибкой."
    - выход 137
  разрешить_сбой:
    выход_коды:
      - 137
      - 255
 
 артефактов  Используйте артефакты  , чтобы указать, какие файлы следует сохранять в качестве артефактов задания.
Артефакты задания — это список файлов и каталогов, которые
привязан к заданию, когда оно успешно, неудачно или всегда.
 Артефакты отправляются в GitLab после завершения задания. Они есть
доступен для загрузки в пользовательском интерфейсе GitLab, если размер меньше, чем
максимальный размер артефакта.
 По умолчанию задания на более поздних этапах автоматически загружают все созданные артефакты
по работам на более ранних стадиях. Вы можете управлять поведением загрузки артефактов в заданиях с помощью  зависимости  .
 При использовании ключевого слова  требуется ключевое слово , задания могут загружаться только
артефакты из заданий, определенных в конфигурации , нуждаются в конфигурации .
 Артефакты заданий по умолчанию собираются только для успешных заданий, и
артефакты восстанавливаются после кешей.
 Подробнее об артефактах.
 артефакты:пути  Пути относятся к каталогу проекта (  $CI_PROJECT_DIR  ) и не могут напрямую
ссылка вне его.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Массив путей к файлам относительно каталога проекта.
 Вы можете использовать подстановочные знаки, которые используют glob
узоры и: В GitLab Runner 13.0 и более поздних версиях  двойная звезда.Глоб  .
 В GitLab Runner 12.10 и более ранних версиях  filepath.Match  .
  Пример  артефактов: пути   :
 задание:
  артефакты:
    пути:
      - двоичные файлы/
      - .конфиг
 
 В этом примере создается артефакт с  .config  и всеми файлами в каталоге  двоичных файлов .
  Дополнительные сведения  :
 Если не используется с  артефактами:имя  , файл артефактов
называется  артефакты  , который при загрузке становится  артефактов.zip .
  Связанные темы  :
 Чтобы ограничить задания, из которых конкретное задание извлекает артефакты, см.  зависимости  .
 Создание артефактов работы.
 Артефакты 
:исключить  История версий
 Представлено в GitLab 13.1
 Требуется GitLab Runner 13.1
 Используйте артефакты : исключайте , чтобы предотвратить добавление файлов в архив артефактов.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Массив путей к файлам относительно каталога проекта.
 Вы можете использовать подстановочные знаки, которые используют glob или  шаблонов doublestar.PathMatch .
  Пример  артефактов: исключить   :
 артефактов:
  пути:
    - двоичные файлы/
  исключать:
    - двоичные файлы /**/*.o
 
 В этом примере все файлы сохраняются в  двоичных файлов/  , но не  *. o  файлов, расположенных в
подкаталоги  двоичных файлов/  .
  Дополнительная информация  :
 Артефакты :исключить  пути не ищутся рекурсивно.
 Файлы, соответствующие  артефактам: неотслеживаемые , могут быть исключены с помощью
 Артефакты : исключить  тоже.
  Похожие темы  :
 Исключите файлы из артефактов задания.
 артефактов:expire_in  История версий
 Представленные в GitLab 13.0 за флагом отключенной функции, последние артефакты заданий сохраняются независимо от времени истечения срока действия.
 Сделано поведение по умолчанию в GitLab 13.4.
 Представленное в GitLab 13.8 сохранение последних артефактов задания можно отключить на уровне проекта.
 Представленное в GitLab 13.9 сохранение последних артефактов задания можно отключить для всего экземпляра.
 Представленные в GitLab 13.12, последние артефакты пайплайна сохраняются независимо от срока действия.
 Используйте  expire_in , чтобы указать, как долго артефакты задания будут храниться до
они истекают и удаляются. Параметр  expire_in  не влияет на:
 Артефакты из последнего задания, за исключением случаев, когда сохранение артефактов последнего задания: Отключено на уровне проекта.
 Отключено для всего экземпляра.
 Артефакты конвейера. Вы не можете указать срок годности для
артефакты конвейера. См. раздел Когда артефакты конвейера удаляются
Чтобы получить больше информации.
 После истечения срока действия артефакты по умолчанию удаляются ежечасно (с помощью задания cron) и не удаляются.
доступны больше.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  : Срок действия. Если единица измерения не указана, время указывается в секундах.
Допустимые значения включают:
  '42' 
  42 секунды 
  3 минуты 4 секунды 
  2 часа 20 мин 
  2H30MIN 
  6 MOS 1 DAY 
  47 YRS 6 MOS и 4D 
  3 недели 9 000 9000 9000  3 недели 018 9000 9000  3 -й недели 9 000 9000  3 -й недели 9 000 9000  3 -й недели. Пример  артефактов:expire_in   :
 задание:
  артефакты:
    expire_in: 1 неделя
 
  Дополнительные сведения  :
 Срок действия начинается с момента загрузки артефакта и его сохранения в GitLab.
Если время истечения срока действия не определено, по умолчанию используется настройка для всего экземпляра.
 Чтобы переопределить дату истечения срока действия и защитить артефакты от автоматического удаления: Выберите  Оставьте  на странице задания.
 В GitLab 13.3 и более поздних версиях установите значение  expire_in  до  никогда  .
 артефактов: expose_as  Представлено в GitLab 12.5.
 Используйте ключевое слово  артефакты: expose_as  для
отображать артефакты работы в пользовательском интерфейсе мерж-реквеста.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Имя, отображаемое в интерфейсе запроса на слияние для ссылки на загрузку артефактов.
Должен сочетаться с  артефактами: пути  .
  Пример  артефактов: expose_as   :
 тест:
  скрипт: ["эхо 'тест' > файл.txt"]
  артефакты:
    expose_as: 'артефакт 1'
    пути: ['file.txt']
 
  Дополнительные сведения  :
 Если  артефакты: пути  используют переменные CI/CD, артефакты не отображаются в пользовательском интерфейсе.
 Максимум 10 артефактов заданий на мерж-реквест.
 Шаблоны шаблонов не поддерживаются.
 Если указан каталог и в нем находится более одного файла,
ссылка на браузер артефактов работы.
 Если GitLab Pages включен, GitLab автоматически
отображает артефакты, когда артефакты представляют собой один файл с одним из следующих расширений:  .html  или  .htm 
  .txt 
  .JSON 
  .XML 
  .log 
  Связанные темтки :
 .
Выставляйте артефакты задания в пользовательском интерфейсе мерж-реквеста.
 артефактов:имя  Используйте ключевое слово  артефакты: имя , чтобы определить имя созданных артефактов.
архив. Вы можете указать уникальное имя для каждого архива.
 Если не определено, имя по умолчанию —  артефакты  , которое при загрузке становится  артефактов. zip .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 Имя архива артефактов. Поддерживаются переменные CI/CD.
Должен сочетаться с  артефактами: пути  .
  Пример  артефактов:имя   :
 Для создания архива с именем текущего задания:
 задание:
  артефакты:
    имя: "job1-файл-артефактов"
    пути:
      - двоичные файлы/
 
  Похожие темы  :
 Используйте переменные CI/CD для определения имени артефакта.
 артефакты: общедоступные  История версий
 Представлен в GitLab 13.8
 Он развернут за флагом функции, отключенным по умолчанию.
 Он отключен на GitLab.com.
 Рекомендуется для промышленного использования.
 В GitLab с самостоятельным управлением по умолчанию эта функция недоступна. Чтобы сделать его доступным,
попросите администратора включить флаг функции с именем  non_public_artifacts  . На
GitLab.com эта функция недоступна.
 Используйте  артефакты: общедоступные , чтобы определить, должны ли артефакты задания
общедоступны.
 Когда  артефакты: общедоступный  равен  true  (по умолчанию), артефакты в
публичные пайплайны доступны для скачивания анонимным и гостевым пользователям.
 Чтобы запретить анонимным и гостевым пользователям доступ на чтение к общедоступным артефактам
конвейеры, набор  артефакты: общедоступные  до  false  :
  Тип ключевого слова  : Ключевое слово задания. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  true  (по умолчанию, если не определено) или  false  .
  Пример  артефактов: общедоступный   :
 задание:
  артефакты:
    публичный: ложь
 
 артефакты:отчеты  Используйте артефакты : отчеты  для сбора артефактов, созданных
включены шаблоны в задания.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 См. список доступных типов отчетов об артефактах.
  Пример  артефактов: отчеты   :
 спецификация:
  этап: тест
  сценарий:
    - пакетная установка
    - rspec --format RspecJunitFormatter --out rspec.xml
  артефакты:
    отчеты:
      соединение: rspec.xml
 
  Дополнительные сведения  :
 Объединение отчетов в родительских конвейерах с использованием артефактов из дочерних конвейеров
не поддерживается. Отслеживайте прогресс добавления поддержки в этом выпуске.
 Чтобы иметь возможность просматривать выходные файлы отчета, включите ключевое слово  артефакты:пути . Обратите внимание, что это загрузит и сохранит артефакт дважды.
 Отчеты о тестировании собираются независимо от результатов задания (успешно или неудачно).
Вы можете использовать артефакты :expire_in  для установки срока действия
дата отчетов об артефактах.
 Артефакты 
: неотслеживаемые  Используйте  артефакты: неотслеживаемые , чтобы добавить все неотслеживаемые файлы Git в качестве артефактов (вместе с
с путями, определенными в артефактах : пути  ). Артефакты : неотслеживаемый  игнорирует конфигурацию
в репозитории  .gitignore  , поэтому включены соответствующие артефакты в  .gitignore  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  true  или  false  (по умолчанию, если не определено).
  Пример  артефактов: неотслеживаемые   :
 Сохранить все неотслеживаемые файлы Git:
 задание:
  артефакты:
    неотслеживаемый: правда
 
  Похожие темы  :
 Добавляйте неотслеживаемые файлы в артефакты.
 Артефакты 
:когда  Использовать артефакты : когда  загружать артефакты при сбое задания или несмотря на
отказ.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  on_success  (по умолчанию): загружать артефакты только в случае успешного выполнения задания.
  on_failure  : Артефакты загружать только в случае сбоя задания.
  всегда  : Всегда загружать артефакты (за исключением случаев, когда время ожидания истекло). Например, когда
загрузка артефактов
требуется для устранения неполадок с провалившимися тестами.
  Пример  артефактов: когда   :
 задание:
  артефакты:
    когда: on_failure
 
 до_скрипта  Используйте  before_script  для определения массива команд, которые должны выполняться перед выполнением каждого задания.  скрипт  команд, но после артефакты восстанавливаются.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : Массив, включающий:
 Однострочные команды.
 Длинные команды разбиты на несколько строк.
 Якоря YAML.
 Поддерживаются переменные CI/CD.
  Пример  before_script   :
 задание:
  до_скрипта:
    - echo "Выполняйте эту команду перед любыми командами 'script:'."
  сценарий:
    - echo "Эта команда выполняется после команд задания 'before_script'."
 
  Дополнительные сведения  : Сценарии, указанные в  before_script , объединяются с любыми указанными вами сценариями.
в основном скрипте   . Объединенные сценарии выполняются вместе в одной оболочке. Использование  before_script  на верхнем уровне, но не на 9Раздел 0816 по умолчанию  устарел.
  Похожие темы  : Используйте  before_script  с  по умолчанию  чтобы определить набор команд по умолчанию, которые должны выполняться перед командами  сценария  во всех заданиях.
 Вы можете игнорировать ненулевые коды выхода.
 Используйте цветовые коды с  before_script  для облегчения просмотра журналов заданий.
 Создание настраиваемых складных разделов
для упрощения вывода журнала заданий.
 кэш  Используйте кэш  , чтобы указать список файлов и каталогов для
кэш между заданиями. Вы можете использовать только те пути, которые есть в локальной рабочей копии.
 Кэширование совместно используется конвейерами и заданиями. Кэши восстанавливаются раньше артефактов.
 Узнайте больше о кэшах в разделе Кэширование в GitLab CI/CD.
 кэш: пути  Используйте ключевое слово  cache:paths , чтобы выбрать файлы или каталоги для кэширования.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Массив путей относительно каталога проекта (  $CI_PROJECT_DIR  ).
Вы можете использовать подстановочные знаки, которые используют glob
узоры: В GitLab Runner 13. 0 и более поздних версиях  двойная звезда.Глоб  .
 В GitLab Runner 12.10 и более ранних версиях  путь к файлу.Соответствует  .
  Пример  cache:paths   :
 Кэшировать все файлы в  двоичных файлах , которые заканчиваются на  .apk  и файл  .config :
 rspec
  сценарий:
    - echo "Это задание использует кеш."
  кеш:
    ключ: бинарные файлы-кэш
    пути:
      - бинарники/*.apk
      - .конфиг
 
  Связанные темы  :
 Дополнительные сведения см. в общих примерах использования кэш-памяти  .  cache:paths  примеров.
 Кэш 
:ключ  Используйте ключевое слово  cache:key , чтобы присвоить каждому кэшу уникальный идентификационный ключ. Все вакансии
которые используют один и тот же ключ кэша, используют один и тот же кэш, в том числе в разных конвейерах.
 Если не задано, ключ по умолчанию  по умолчанию  . Все задания с ключевым словом  cache , но
нет кэша : ключ  совместно использует кэш  по умолчанию .
 Должен использоваться с кешем : путь  , иначе ничего не кэшируется.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 Строка.
 Предопределенная переменная CI/CD.
 Комбинация обоих.
  Пример  cache:key   :
 cache-job:
  сценарий:
    - echo "Это задание использует кеш."
  кеш:
    ключ: бинарные-кэш-$CI_COMMIT_REF_SLUG
    пути:
      - двоичные файлы/
 
  Дополнительная информация  :
  Связанные темы  :
 Вы можете указать резервный ключ кэша
использовать, если указанный кэш : ключ  не найден.
 В одном задании можно использовать несколько ключей кэша.
 Дополнительные сведения см. в общих примерах использования кэш-памяти  .
 Кэш : примеры ключей .
 кэш:ключ:файлы  Представлено в GitLab 12.5.
 Используйте ключевое слово  cache:key:files  для создания нового ключа, когда один или два определенных файла
сдача.  cache:key:files  позволяет повторно использовать некоторые кэши и реже их перестраивать,
что ускоряет последующие запуски конвейера.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Массив из одного или двух путей к файлам.
  Пример  cache:key:files   :
 cache-job:
  сценарий:
    - echo "Это задание использует кеш. "
  кеш:
    ключ:
      файлы:
        - Gemfile.lock
        - пакет.json
    пути:
      - продавец/рубин
      - node_modules
 
 В этом примере создается кэш для зависимостей Ruby и Node.js. Кэш
привязан к текущим версиям файлов  Gemfile.lock  и  package.json . Когда один из
эти файлы изменяются, вычисляется новый ключ кэша и создается новый кэш. Любое будущее
выполнение заданий, использующих один и тот же  Gemfile.lock  и  package.json  с  cache:key:files  используйте новый кеш вместо перестроения зависимостей.
  Дополнительная информация  : Ключ  кэша  — это SHA, вычисленный на основе самых последних коммитов.
который изменил каждый из перечисленных файлов.
Если ни один из файлов не был изменен ни при каких коммитах, резервным ключом будет  по умолчанию  .
 кэш: ключ: префикс  Представлено в GitLab 12. 5.
 Используйте  cache:key:prefix  для объединения префикса с SHA, вычисленным для  cache:key:files  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 Строка
 Предопределенные переменные
 Комбинация обоих.
  Пример  cache:key:prefix   :
 rspec:
  сценарий:
    - echo "Это задание rspec использует кеш."
  кеш:
    ключ:
      файлы:
        - Gemfile.lock
      префикс: $CI_JOB_NAME
    пути:
      - продавец/рубин
 
 Например, добавление префикса   к  $CI_JOB_NAME  приводит к тому, что ключ выглядит как  rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5  .
Если ветвь изменяет  Gemfile.lock  , эта ветвь имеет новую контрольную сумму SHA для  cache:key:files  . Генерируется новый ключ кэша, и для этого ключа создается новый кэш. Если  Gemfile.lock  не найден, к  добавляется префикс default  , поэтому ключ в примере будет  rspec-default  .
  Дополнительная информация  : Если ни один файл в  cache:key:files  не изменяется ни в одной фиксации, к ключу  по умолчанию  добавляется префикс.
 Кэш 
: не отслеживается  Используйте  untracked: true  для кэширования всех неотслеживаемых файлов в вашем репозитории Git:
  Тип ключевого слова  : Ключевое слово задания. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  правда  или  ложь  (по умолчанию).
  Пример  cache:untracked   :
 rspec:
  сценарий: тест
  кеш:
    неотслеживаемый: правда
 
  Дополнительные детали  :
 Кэш 
: когда  Представлено в GitLab 13. 5 и GitLab Runner v13.5.0.
 Использовать кэш :когда  для определения времени сохранения кэша в зависимости от состояния задания.
 Должен использоваться с кешем : путь  , иначе ничего не кэшируется.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  on_success  (по умолчанию): сохранять кеш только в случае успешного выполнения задания.
  on_failure  : Сохранять кеш только в случае сбоя задания.
  всегда  : Всегда сохранять кеш.
  Пример кэша : когда   :
 rspec:
  сценарий: rspec
  кеш:
    пути:
      - рспец/
    когда: «всегда»
 
 В этом примере кэш сохраняется независимо от того, завершается ли задание неудачно или успешно.
 кэш: политика  Чтобы изменить поведение загрузки и загрузки кэша, используйте ключевое слово  cache:policy . По умолчанию задание загружает кэш при запуске задания и отправляет изменения
в кеш после завершения задания. Этот стиль кэширования представляет собой политику  pull-push  (по умолчанию).
 Чтобы настроить задание на загрузку кэша только при запуске задания, но никогда не загружать изменения
когда работа закончится, используйте  кеш:политика:тянуть  .
 Чтобы настроить задание на загрузку кэша только после завершения задания, но никогда не загружать
cache при запуске задания используйте  cache:policy:push  .
 Используйте политику  pull , если у вас параллельно выполняется много заданий, использующих один и тот же кэш.
Эта политика ускоряет выполнение заданий и снижает нагрузку на сервер кэширования. Вы можете
используйте задание с политикой  push  для создания кэша.
 Должен использоваться с кэшем : путь  или ничего не кэшируется.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  тянуть 
  нажимать 
  pull-push  (по умолчанию)
  Пример  cache:policy   :
 prepare-dependencies-job:
  этап: сборка
  кеш:
    ключ: драгоценные камни
    пути:
      - продавец/комплект
    политика: нажать
  сценарий:
    - echo "Это задание только загружает зависимости и создает кеш."
    - echo "Загрузка зависимостей..."
более быстрая тестовая работа:
  этап: тест
  кеш:
    ключ: драгоценные камни
    пути:
      - продавец/комплект
    политика: тянуть
  сценарий:
    - echo "Этот сценарий задания использует кеш, но не обновляет его."
    - echo "Выполнение тестов..."
 
 покрытие  Используйте покрытие   с настраиваемым регулярным выражением для настройки покрытия кода
извлекается из выходных данных задания. Покрытие отображается в пользовательском интерфейсе, если хотя бы один
строка в выводе задания соответствует регулярному выражению.
 Чтобы извлечь значение покрытия кода из совпадения, GitLab использует
это меньшее регулярное выражение:  \d+(\.\d+)?  .
  Возможные входные данные  :
 Регулярное выражение. Должен начинаться и заканчиваться на /. Должен совпадать с номером покрытия.
Также может соответствовать окружающему тексту, поэтому вам не нужно использовать группу символов регулярного выражения.
чтобы зафиксировать точное число.
  Пример покрытия    :
 job1:
  сценарий: rspec
  покрытие: '/Покрытие кода: \d+\.\d+/'
 
 В этом примере:
 GitLab проверяет журнал заданий на соответствие регулярному выражению. Линия
как  Покрытие кода: 67,89% строк, охваченных , совпадут.
 Затем GitLab проверяет совпадающий фрагмент, чтобы найти совпадение с  \d+(\. \d+)?  .
Примерная строка соответствия выше дает покрытие кода  67,89  .
  Дополнительные сведения  :
 Если в выходных данных задания имеется более одной совпадающей строки, используется последняя строка.
(первый результат обратного поиска).
 Если в одной строке несколько совпадений, ищется последнее совпадение
для номера покрытия.
 Если в совпадающем фрагменте найдено несколько номеров покрытия, используется первый номер.
 Ведущие нули удалены.
 Выход покрытия из дочерних конвейеров
не записывается и не отображается. Проверьте связанную проблему
Больше подробностей.
 dast_configuration  Представлено в GitLab 14.1.
 Используйте ключевое слово  dast_configuration , чтобы указать профиль сайта и профиль сканера, которые будут использоваться в
Конфигурация CI/CD. Оба профиля должны быть предварительно созданы в проекте. Этап работы должен
быть  дат  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать только как часть работы.
  Возможные входы  : По одному из  site_profile  и  scan_profile  .
 Используйте  site_profile , чтобы указать профиль сайта, который будет использоваться в задании.
 Используйте  scan_profile , чтобы указать профиль сканера, который будет использоваться в задании.
  Пример  dast_configuration   :
 этапов:
  - строить
  - даст
включают:
  - шаблон: DAST.gitlab-ci.yml
даст:
  dast_configuration:
    site_profile: "Пример компании"
    Scanner_profile: "Быстрый пассивный тест"
 
 В этом примере задание  dast  расширяет конфигурацию  dast , добавленную с помощью ключевого слова  include .
для выбора конкретного профиля сайта и профиля сканера.
  Дополнительные сведения  :
 Настройки, содержащиеся либо в профиле сайта, либо в профиле сканера, имеют приоритет над
содержится в шаблоне DAST.
  Похожие темы  :
 Профиль сайта.
 Профиль сканера.
 зависимостей  Используйте ключевое слово  зависимостей , чтобы определить список заданий, из которых будут извлекаться артефакты.
Вы также можете настроить задание, чтобы вообще не загружать артефакты.
 Если вы не используете  зависимости  , все артефакты с предыдущих этапов передаются каждому заданию.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Имена заданий, из которых нужно получить артефакты.
 Пустой массив (  []  ), чтобы задание не загружало никаких артефактов.
  Пример  зависимостей   :
 build osx:
  этап: сборка
  сценарий: сделать сборку: osx
  артефакты:
    пути:
      - двоичные файлы/
собрать линукс:
  этап: сборка
  скрипт: make build:linux
  артефакты:
    пути:
      - двоичные файлы/
тестовый osx:
  этап: тест
  сценарий: сделать тест: osx
  зависимости:
    - собрать ОСХ
тестовый линукс:
  этап: тест
  сценарий: сделать тест: Linux
  зависимости:
    - собрать линукс
развертывать:
  этап: развертывание
  скрипт: сделать деплой
  среда: производство
 
 В этом примере у двух заданий есть артефакты:  build osx  и  build linux  . Когда выполняется  test osx ,
артефакты из сборки  OSX  загружаются и извлекаются в контексте сборки.
То же самое происходит для  test linux  и артефактов из  build linux .
 Задание  развертывания  загружает артефакты из всех предыдущих заданий из-за
приоритет этапа.
  Дополнительная информация  :
 Статус задания не имеет значения. Если задание завершается сбоем или это ручное задание, которое не запускается, ошибка не возникает.
 Если артефакты зависимого задания просрочены или
удаляется, то задание не выполняется.
 окружающая среда  Используйте среду   для определения среды, в которой развертывается задание.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Имя среды, в которой развертывается задание, в одном из этих
форматы:
 Простой текст, включая буквы, цифры, пробелы и следующие символы:  - ,  _ ,  / ,  $ ,  { ,  } .
 Переменные CI/CD, включая предопределенные, проектные, групповые, экземплярные или переменные, определенные в  .gitlab-ci.yml  файл. Вы не можете использовать переменные, определенные в разделе  скрипта .
  Пример развертывания среды    :
 в рабочей среде:
  этап: развертывание
  скрипт: git push production HEAD:main
  среда: производство
 
  Дополнительные сведения  :
 Если вы укажете среду   и среда с таким именем не существует, среда
созданный.
 среда: имя  Установите имя для среды.
 Общие имена сред:  qa  ,  staging  и  production  , но вы можете использовать любое имя.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Имя среды, в которой развертывается задание, в одном из этих
форматы: Обычный текст, включая буквы, цифры, пробелы и следующие символы:  - ,  _ ,  / ,  $ ,  { , } .
 переменные CI/CD,
включая предопределенные, проект, группу, экземпляр или переменные, определенные в  .gitlab-ci.yml  файл. Вы не можете использовать переменные, определенные в сценарии  9раздел 0817.
  Пример  environment:name   :
 развертывание в рабочей среде:
  этап: развертывание
  скрипт: git push production HEAD:main
  Окружающая среда:
    Название: производство
 
 среда: URL-адрес  Установите URL-адрес для среды.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Один URL-адрес в одном из следующих форматов: Простой текст, например  https://prod.example.com  . переменные CI/CD,
включая предопределенные, проект, группу, экземпляр или переменные, определенные в  .gitlab-ci.yml  файл. Вы не можете использовать переменные, определенные в разделе  скрипта .
  Пример среды : URL-адрес   :
 развертывания в рабочей среде:
  этап: развертывание
  скрипт: git push production HEAD:main
  Окружающая среда:
    Название: производство
    URL-адрес: https://prod.example.com
 
  Дополнительная информация  :
 После завершения задания вы можете получить доступ к URL-адресу, нажав кнопку в запросе на слияние,
среды или страницы развертывания.
 среда: on_stop  Закрытие (остановка) среды может быть достигнуто с помощью ключевого слова  on_stop  определено в среде   . Он объявляет другое задание, которое запускается, чтобы закрыть
Окружающая среда.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Дополнительные сведения  :
 См.  environment:action  для получения дополнительных сведений и примера.
 среда: действие  Используйте ключевое слово  action , чтобы указать, как задание взаимодействует со средой.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  : Одно из следующих ключевых слов:
  Значение   Описание 
  пуск  Значение по умолчанию. Указывает, что задание запускает среду. Развертывание создается после запуска задания.
  подготовка  Указывает, что задание только подготавливает среду. Он не запускает развертывания. Узнайте больше о подготовке сред.
  stop  Указывает, что задание останавливает развертывание. Дополнительные сведения см. в разделе Остановить среду.
  проверка  Указывает, что задание проверяет только среду. Он не запускает развертывания. Узнайте больше о проверке сред.
  доступ  Указывает, что задание обращается только к среде. Он не запускает развертывания. Узнайте больше о доступе к средам.
  Пример  environment:action   :
 stop_review_app:
  этап: развертывание
  переменные:
    GIT_STRATEGY: нет
  скрипт: сделать удаление-приложение
  когда: вручную
  Окружающая среда:
    имя: обзор/$CI_COMMIT_REF_SLUG
    действие: стоп
 
 среда: auto_stop_in  Представлено в GitLab 12.8.
 Ключевое слово  auto_stop_in  определяет время существования среды. Когда срок действия среды истекает, GitLab
автоматически останавливает его.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Период времени, записанный на естественном языке. Например,
все они эквивалентны:
  168 часов 
  7 дней 
  Одна неделя 
  Никогда 
  Пример  Среда: AUTO_STOP_IN  :
3333331t ОБЗОР: AUTO_STOP_IN  :
33333331t review_stop_in 
  :
333333331t ОБЗОР.
 сценарий: развертывание-обзор-приложение
 Окружающая среда:
 имя: обзор/$CI_COMMIT_REF_SLUG
 auto_stop_in: 1 день 
 При создании среды для  review_app  срок жизни среды устанавливается равным  1 день  .
Каждый раз, когда развертывается приложение для проверки, это время жизни также сбрасывается до 9.0816 1 день  .
  Похожие темы  :
 Документация по автоматической остановке сред.
 среда: Kubernetes  Представлено в GitLab 12.6.
 Используйте ключевое слово  kubernetes  для настройки развертываний на
Кластер Kubernetes, связанный с вашим проектом.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Пример среды : kubernetes   :
 развертывание:
  этап: развертывание
  скрипт: сделать деплой-приложение
  Окружающая среда:
    Название: производство
    кубернет:
      пространство имен: производство
 
 Эта конфигурация настраивает задание развертывания   для развертывания в рабочей среде   среды, используя  производство  Пространство имен Kubernetes.
  Дополнительные сведения  :
 Конфигурация Kubernetes не поддерживается для кластеров Kubernetes
которыми управляет GitLab.
Чтобы следить за ходом поддержки кластеров, управляемых GitLab, см. актуальная проблема.
  Похожие темы  :
 Доступные настройки для  kubernetes .
 среда: уровень развертывания  Представлено в GitLab 13.10.
 Используйте ключевое слово  deployment_tier , чтобы указать уровень среды развертывания.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  : Один из следующих:
  Производство 
  Постановка 
  Тестирование 
  Development 
  DESHING 
  Пример .
 сценарий: эхо
 Окружающая среда:
 название: клиентский портал
 уровень_развертывания: производство 
  Похожие темы  :
 Уровень развертывания сред.
 Динамические среды 
 Используйте переменные CI/CD для динамического присвоения имен средам.
 Например:
 развертывание в качестве приложения для проверки:
  этап: развертывание
  скрипт: сделать деплой
  Окружающая среда:
    имя: обзор/$CI_COMMIT_REF_SLUG
    URL-адрес: https://$CI_ENVIRONMENT_SLUG.example.com/
 
 Задание  развертывания в качестве приложения проверки  помечено как развертывание для динамического
создайте среду  review/$CI_COMMIT_REF_SLUG .  $CI_COMMIT_REF_SLUG  — это переменная CI/CD, устанавливаемая исполнителем.  Переменная $CI_ENVIRONMENT_SLUG  основана на имени среды, но подходит
для включения в URL. Если задание  развертывания в качестве приложения проверки  выполняется в ветке с именем  pow  , эта среда будет доступна по URL-адресу, например  https://review-pow.example.com/  .
 Обычный вариант использования — создание динамических сред для филиалов и их использование
как приложения для просмотра. Вы можете увидеть пример, который использует Review Apps на
https://gitlab. com/gitlab-examples/review-apps-nginx/.
 расширяет  Использование  расширяет  для повторного использования разделов конфигурации. Это альтернатива анкорам YAML.
и немного более гибкий и читабельный.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Имя другого задания в конвейере.
 Список (массив) имен других заданий в конвейере.
  Пример расширения    :
 .тесты:
  скрипт: рейк-тест
  этап: тест
  Только:
    ссылки:
      - ветви
rspec:
  расширяет: .tests
  скрипт: грабли rspec
  Только:
    переменные:
      - $RSPEC
 
 В этом примере задание  rspec  использует конфигурацию шаблонного задания  .tests .
При создании конвейера GitLab:
 Выполняет обратное глубокое слияние на основе ключей.
 Объединяет содержимое  . tests  с заданием  rspec .
 Не объединяет значения ключей.
 Результат:  rspec  job:
 rspec:
  скрипт: грабли rspec
  этап: тест
  Только:
    ссылки:
      - ветви
    переменные:
      - $RSPEC
 
  Дополнительные сведения  :
 В GitLab 12.0 и более поздних версиях вы можете использовать несколько родителей для  extends  .
 Ключевое слово  расширяет ключевое слово , поддерживает до одиннадцати уровней наследования, но вы должны
избегайте использования более трех уровней.
 В приведенном выше примере  .tests  является скрытым заданием,
но вы также можете расширить конфигурацию из обычных заданий.
  Похожие темы  :
 Повторное использование разделов конфигурации с помощью  extends  .
 Использование  расширяет  для повторного использования конфигурации из включенных файлов конфигурации.
 изображение  Используйте образ  , чтобы указать образ Docker, в котором выполняется задание.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : Имя образа, включая путь реестра, если необходимо, в одном из следующих форматов:
    (То же, что и при использовании    с последним тегом  )
  : 
  @ 
 Поддерживаются переменные CI/CD.
  Пример изображения    :
 по умолчанию:
  изображение: рубин: 3.0
rspec:
  скрипт: пакет exec rspec
рспец 2.7:
  образ:Registry.example.com/my-group/my-project/ruby:2.7
  скрипт: пакет exec rspec
 
 В этом примере образ  ruby:3. 0  используется по умолчанию для всех заданий в конвейере.
Задание  rspec 2.7  не использует значение по умолчанию, поскольку оно переопределяет значение по умолчанию с помощью
конкретная работа  изображение  раздел.
  Похожие темы  :
 Запускайте задания CI/CD в контейнерах Docker.
 изображение:имя  Имя образа Docker, в котором выполняется задание. Аналогично  образу , который используется сам по себе.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : Имя образа, включая путь реестра, если необходимо, в одном из следующих форматов:
    (То же, что и при использовании    с последним тегом  )
  : 
  @ 
  Пример  изображение:имя   :
 изображение:
  имя: "registry. example.com/my/image:latest"
 
  Похожие темы  :
 Запускайте задания CI/CD в контейнерах Docker.
 изображение: точка входа  Команда или сценарий для выполнения в качестве точки входа контейнера.
 При создании контейнера Docker точка входа   преобразуется в параметр Docker  --entrypoint .
Синтаксис аналогичен директиве Dockerfile  ENTRYPOINT ,
где каждый токен оболочки представляет собой отдельную строку в массиве.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 Строка.
  Пример изображения : точка входа   :
 изображение:
  имя: супер/sql:экспериментальный
  точка входа: [""]
 
  Похожие темы  :
 Переопределить точку входа изображения.
 изображение:pull_policy  История версий Представлен в GitLab 15.1 с флагом 9.0816 ci_docker_image_pull_policy  . Отключено по умолчанию.
 Включено на GitLab.com и самостоятельно управляется в GitLab 15.2.
 Обычно доступно в GitLab 15.4. Флаг функции  ci_docker_image_pull_policy  удален.
 Требуется GitLab Runner 15.1 или новее.
 Политика извлечения, используемая исполнителем для получения образа Docker.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть задания или в разделе  по умолчанию .
  Возможные входные данные  :
 Одна политика извлечения или несколько политик извлечения в массиве.
Может быть  всегда  ,  если нет  , или  никогда  .
  Примеры  image:pull_policy   :
 job1:
  script: echo "Единая политика извлечения". 
  изображение:
    имя: рубин: 3.0
    pull_policy: если нет
задание2:
  script: echo "Несколько политик извлечения".
  изображение:
    имя: рубин: 3.0
    pull_policy: [всегда, если нет]
 
  Дополнительные сведения  :
 Если средство выполнения не поддерживает заданную политику извлечения, задание завершается с ошибкой, подобной следующей:  ОШИБКА: Сбой задания (сбой системы): настроенные политики PullPolicies ([всегда]) не разрешены AllowedPullPolicies ([никогда])  .
  Похожие темы  :
 Запускайте задания CI/CD в контейнерах Docker.
 Как работают политики вытягивания бегунов.
 Использование нескольких политик вытягивания.
 наследует  Представлено в GitLab 12.9.
 Используйте  наследовать  для управления наследованием ключевых слов и переменных по умолчанию.
 наследовать: по умолчанию  Используйте  inherit:default  для управления наследованием ключевых слов по умолчанию.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  правда  (по умолчанию) или  false , чтобы включить или отключить наследование всех ключевых слов по умолчанию.
 Список определенных ключевых слов по умолчанию для наследования.
  Пример наследования : по умолчанию   :
 по умолчанию:
  повторить: 2
  изображение: рубин: 3.0
  прерываемый: правда
задание1:
  script: echo "Это задание не наследует ключевые слова по умолчанию."
  наследовать:
    по умолчанию: ложь
задание2:
  script: echo "Это задание наследует только два перечисленных ключевых слова по умолчанию. Оно не наследует прерываемое".
  наследовать:
    дефолт:
      - повторить попытку
      - изображение
 
  Дополнительные сведения  :
 Вы также можете перечислить ключевые слова по умолчанию для наследования в одной строке:  по умолчанию: [ключевое слово1, ключевое слово2] 
 наследовать: переменные  Используйте  inherit:variables  для управления наследованием ключевых слов глобальных переменных.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  правда  (по умолчанию) или  false , чтобы включить или отключить наследование всех глобальных переменных.
 Список определенных переменных для наследования.
  Пример  inherit:variables   :
 переменных:
  VARIABLE1: «Это переменная 1»
  ПЕРЕМЕННАЯ2: «Это переменная 2»
  VARIABLE3: «Это переменная 3»
задание1:
  script: echo "Это задание не наследует глобальные переменные."
  наследовать:
    переменные: ложь
задание2:
  script: echo "Это задание наследует только две перечисленные глобальные переменные. Оно не наследует 'VARIABLE3'."
  наследовать:
    переменные:
      - ПЕРЕМЕННАЯ1
      - ПЕРЕМЕННАЯ2
 
  Дополнительные сведения  :
 Вы также можете перечислить глобальные переменные для наследования в одной строке:  переменных: [ПЕРЕМЕННАЯ1, ПЕРЕМЕННАЯ2] 
 прерываемый  Представлено в GitLab 12. 3.
 Используйте прерываемый  , если задание должно быть отменено, когда новый конвейер запускается до завершения задания.
 Это ключевое слово не действует, если выполняется автоматическая отмена избыточных конвейеров.
выключен. При включении работающее задание с  прерываемый: true  отменяется, когда
запуск конвейера для нового изменения в той же ветке.
 Вы не можете отменить последующие задания после запуска задания с прерыванием : false .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  истина  или  ложь  (по умолчанию).
  Пример  прерываемый   :
 ступени:
  - этап 1
  - этап2
  - стадия 3
шаг 1:
  этап: этап1
  сценарий:
    - эхо "Можно отменить."
  прерываемый: правда
шаг 2:
  этап: этап2
  сценарий:
    - эхо "Не может быть отменено. "
шаг 3:
  этап: этап 3
  сценарий:
    - echo "Поскольку шаг 2 не может быть отменен, этот шаг никогда не может быть отменен, даже если он установлен как прерываемый."
  прерываемый: правда
 
 В этом примере новый конвейер приводит к тому, что работающий конвейер становится:
 Отменено, если только  шаг-1  выполняется или находится в ожидании.
 Не отменяется, после  шаг-2 запускается .
  Дополнительные сведения  :
 Установите только  прерывание: true , если задание можно безопасно отменить после его запуска,
как строительная работа. Задания развертывания обычно не следует отменять, чтобы предотвратить частичное развертывание.
 Чтобы полностью отменить работающий конвейер, все задания должны иметь прерывание : true  ,
или  прерываемый: false  задания не должны быть запущены.
 нужно  История версий
 Представлено в GitLab 12. 2.
 В GitLab 12.3 для максимального количества заданий в  требуется массив , увеличенный с пяти до 50.
 Представленный в GitLab 12.8,  требует: []  позволяет запускать задания немедленно.
 Представленный в GitLab 14.2, вы можете обращаться к заданиям на том же этапе, что и задание, которое вы настраиваете.
 Использование  требует  для выполнения заданий не по порядку. Отношения между рабочими местами
что использование  требует , можно представить в виде ориентированного ациклического графа.
 Можно игнорировать порядок этапов и выполнять одни задания, не дожидаясь завершения других.
Задания на нескольких этапах могут выполняться одновременно.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Массив заданий.
 Пустой массив (  []  ), чтобы задание запускалось сразу после создания конвейера.
  Пример  потребностей   :
 linux:build:
  этап: сборка
  скрипт: echo "Сборка Linux..."
мак:сборка:
  этап: сборка
  script: echo "Сборка Mac..."
корпия:
  этап: тест
  потребности: []
  скрипт: echo "Линтинг..."
линукс: rspec:
  этап: тест
  потребности: ["linux:сборка"]
  script: echo "Запуск rspec в Linux..."
макинтош: rspec:
  этап: тест
  потребности: ["mac:сборка"]
  script: echo "Запуск rspec на Mac..."
производство:
  этап: развертывание
  script: echo "Выполняется производство..."
  среда: производство
 
 В этом примере создаются четыре пути выполнения:
 Линтер: задание  lint  запускается немедленно, не дожидаясь стадии  сборки .
для завершения, потому что в нем нет нужды (  need: []  ).
 Путь Linux: задание  linux:rspec  запускается, как только  linux:build  задание завершается, не дожидаясь завершения  mac:build .
 путь macOS: задания  mac:rspec  запускаются, как только  mac:build  задание завершается, не дожидаясь завершения  linux:build .
 Задание  production  запускается сразу после завершения всех предыдущих заданий:  linux:сборка  ,  linux:rspec  ,  mac:сборка  ,  mac:rspec  .
  Дополнительные сведения  :
 Максимальное количество заданий, которое может иметь одно задание в массиве , требует , ограничено: Для GitLab.com ограничение составляет 50. Для получения дополнительной информации см.
вопрос инфраструктуры.
 Для самоуправляемых экземпляров ограничение по умолчанию равно 50. Это ограничение можно изменить.
 Если  требуется,  относится к заданию, в котором используется ключевое слово  parallel ,
это зависит от всех заданий, созданных параллельно, а не только от одного задания. Он также загружает
артефакты из всех параллельных заданий по умолчанию. Если артефакты одинаковые
имя, они перезаписывают друг друга и сохраняется только последнее загруженное.
 В GitLab 14.1 и более поздних версиях вы
может ссылаться на задания на том же этапе, что и задание, которое вы настраиваете. Эта функция
включен на GitLab.com и готов к использованию в продакшене. На самоуправляемом GitLab 14.2 и более поздних версиях
эта функция доступна по умолчанию.
 В GitLab 14.0 и старше вы можете ссылаться только на задания на более ранних стадиях. Этапы должны быть
явно определено для всех заданий, которые используют ключевое слово  need  или на которые ссылаются
в задании  нужен раздел .
 В GitLab 13.9 и старше, если  требуется,  относится к заданию, которое нельзя добавить в
конвейер из-за  только  ,  кроме  или  правил  , конвейер может не создаться.
 нужно:артефакты  Представлено в GitLab 12. 6.
 Когда задание использует , требуется , оно больше не загружает все артефакты с предыдущих этапов.
по умолчанию, поскольку задания с  требуют , могут начаться до завершения более ранних этапов. С  требуется , вы можете загружать артефакты только из заданий, перечисленных в конфигурации  требуется .
 Использовать артефакты : true  (по умолчанию) или артефакты : false , чтобы контролировать, когда артефакты
загружается в задания, которые используют  нужно .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы. Должен использоваться с  need:job  .
  Возможные входы  :
  true  (по умолчанию) или  false  .
  Пример потребности : артефакты   :
 test-job1:
  этап: тест
  потребности:
    - задание: build_job1
      артефакты: правда
тестовая работа2:
  этап: тест
  потребности:
    - задание: build_job2
      артефакты: ложь
тестовая работа3:
  потребности:
    - задание: build_job1
      артефакты: правда
    - задание: build_job2
    - build_job3
 
 В этом примере:
 Задание  test-job1  загружает артефакты  build_job1 
 Задание  test-job2  не загружает артефакты  build_job2 .
 Задание  test-job3  загружает артефакты из всех трех  build_jobs  , потому что  артефактов  равно  true  или по умолчанию  true  для всех трех необходимых заданий.
  Дополнительная информация  :
 В GitLab 12.6 и более поздних версиях вы не можете комбинировать ключевое слово  зависимостей .
с  нужно  .
 потребности:проект  Представлено в GitLab 12.7.
 Используйте  need:project  для загрузки артефактов из пяти заданий в других конвейерах.
Артефакты загружаются из последнего успешного конвейера для указанной ссылки.
Чтобы указать несколько заданий, добавьте каждое из них в виде отдельных элементов массива в соответствии с потребностями .  ключевое слово.
 Если для указанной ссылки запущен конвейер, задание с  требует: проект  не ждет завершения конвейера. Вместо этого задание загружает артефакт
из последнего успешно завершенного конвейера.
  потребности: проект  должен использоваться с  заданием  ,  ref  и  артефактами  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  need:project  : Полный путь к проекту, включая пространство имен и группу.
  job  : задание для загрузки артефактов.
  ref  : ссылка для загрузки артефактов.
  артефактов  : для загрузки артефактов должно быть  истинное .
  Примеры потребностей : проект   :
 build_job:
  этап: сборка
  сценарий:
    - лс -лр
  потребности:
    - проект: пространство имен/группа/имя-проекта
      работа: сборка-1
      ссылка: основной
      артефакты: правда
    - проект: пространство имен/группа/имя-проекта-2
      задание: сборка-2
      ссылка: основной
      артефакты: правда
 
 В этом примере  build_job  загружает артефакты из последних успешных заданий  build-1  и  build-2 . на основных ветках   в проектах  group/project-name  и  group/project-name-2 .
 В GitLab 13.3 и более поздних версиях вы можете использовать переменные CI/CD
в  потребности:проект  , например:
 build_job:
  этап: сборка
  сценарий:
    - лс -лр
  потребности:
    - проект: $CI_PROJECT_PATH
      задание: $DEPENDENCY_JOB_NAME
      ссылка: $ARTIFACTS_DOWNLOAD_REF
      артефакты: правда
 
  Дополнительные сведения  :
 Чтобы загрузить артефакты из другого конвейера в текущем проекте, установите  проект  быть таким же, как текущий проект, но использовать другую ссылку, чем текущий конвейер.
Параллельные конвейеры, работающие на одной и той же ссылке, могут переопределять артефакты.
 Пользователь, запускающий конвейер, должен иметь как минимум роль Reporter для группы или проекта,
или группа/проект должны быть общедоступны.
 Вы не можете использовать  нуждается: проект  в том же задании, что и , запускает  .
 При использовании  требуется: проект  для загрузки артефактов из другого конвейера, задание не ожидает
необходимую работу для завершения. Направленный ациклический граф
поведение ограничено заданиями в одном конвейере. Убедитесь, что нужная работа в другом
конвейер завершится до того, как требующее его задание попытается загрузить артефакты.
 Вы не можете загружать артефакты из заданий, которые выполняются  параллельно  .
 Поддержка переменных CI/CD в  проекте ,  задании  и  ref  была
представлен в GitLab 13.3.
Флаг функции удален в GitLab 13.4.
  Связанные темы  :
 Чтобы загрузить артефакты между родительско-дочерними конвейерами,
используйте  need:pipeline:job  .
 потребности:конвейер:работа  Представлено в GitLab 13.7.
 Дочерний конвейер может загружать артефакты из задания в
его родительский конвейер или другой дочерний конвейер в той же иерархии родительско-дочерних конвейеров.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  need:pipeline  : ID конвейера. Должен быть конвейером, присутствующим в той же иерархии родительско-дочернего конвейера.
  job  : задание для загрузки артефактов.
  Пример  need:pipeline:job   :
 Родительский конвейер (  .gitlab-ci.yml  ):
 создать артефакт:
  этап: сборка
  скрипт: эхо "образец артефакта" > артефакт.txt
  артефакты:
    пути: [artifact.txt]
дочерний конвейер:
  этап: тест
  курок:
    включают: child.yml
    стратегия: зависеть
  переменные:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID
 
 Дочерний конвейер (  child.yml  ):
 use-artifact:
  скрипт: артефакт кота.txt
  потребности:
    - конвейер: $PARENT_PIPELINE_ID
      задание: создать артефакт
 
 В этом примере 9Задание 0816 create-artifact  в родительском конвейере создает некоторые артефакты. Задание  child-pipeline  запускает дочерний конвейер и передает  CI_PIPELINE_ID  в дочерний конвейер как новую переменную  PARENT_PIPELINE_ID . Дочерний конвейер
можно использовать эту переменную в  need:pipeline  для загрузки артефактов из родительского конвейера.
  Дополнительные сведения  :
 Атрибут  конвейера  не принимает идентификатор текущего конвейера (  $CI_PIPELINE_ID  ).
Чтобы загрузить артефакты из задания в текущем конвейере, используйте , необходимо  .
 потребности: опционально  История версий
 Представлено в GitLab 13.10.
 Флаг функции удален в GitLab 14.0.
 Чтобы выполнить задание, которого иногда нет в конвейере, добавьте  (необязательно): true  для  требуется конфигурация . Если не определено,  необязательно: false  по умолчанию.
 Задания, использующие правила  , только   или , кроме , могут не всегда
быть добавлен в конвейер. GitLab проверяет отношения  need  перед запуском
конвейер:
 Если в записи потребностей есть , необязательно: true  и необходимое задание присутствует в конвейере,
задание ожидает завершения перед запуском.
 Если нужное задание отсутствует, задание можно запустить, когда будут выполнены все остальные требования.
 Если  нуждается в разделе , содержит только необязательные задания, и ни одно из них не добавляется в конвейер,
задание запускается немедленно (так же, как для пустого  требуется запись :  требуется: []  ).
 Если нужное задание имеет  option: false  , но оно не было добавлено в конвейер,
Конвейер не запускается с ошибкой, похожей на:  Задание 'job1' нуждается в задании 'job2', но оно не было добавлено в конвейер  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Пример потребности : опционально   :
 build-job:
  этап: сборка
тестовая работа1:
  этап: тест
тестовая работа2:
  этап: тест
  правила:
    - если: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
развертывание-работа:
  этап: развертывание
  потребности:
    - работа: тестовая работа2
      необязательно: правда
    - работа: тестовая работа1
  среда: производство
обзор-работа:
  этап: развертывание
  потребности:
    - работа: тестовая работа2
      необязательно: правда
  среда: обзор
 
 В этом примере:
  сборка-задание  ,  test-job1  и  test-job2  запускаются в порядке этапов.
 Если ветвь является ветвью по умолчанию,  test-job2  добавляется в конвейер, поэтому:  deploy-job  ожидает завершения  test-job1  и  test-job2 .
  review-job  ожидает завершения  test-job2 .
 Если ветвь не является ветвью по умолчанию,  test-job2  не добавляется в конвейер, поэтому:  deploy-job  ожидает завершения только  test-job1  и не ждет отсутствующего  test-job2  .
  review-job  не имеет других необходимых заданий и запускается немедленно (в то же время, что и  build-job  ),
как  нужно: []  .
 потребности: конвейер  Вы можете отразить состояние конвейера от вышестоящего конвейера до задания моста,
используя  need:pipeline  ключевое слово. Последний статус конвейера из ветки по умолчанию:
реплицируется на задание моста.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Полный путь к проекту, включая пространство имен и группу. Если
проект находится в той же группе или пространстве имен, вы можете опустить их из проекта   ключевое слово. Например: проект : имя группы/проекта  или проект : имя проекта  .
  Пример потребности : трубопровод   :
 upstream_bridge:
  этап: тест
  потребности:
    воронка: другое/проект
 
  Дополнительные сведения  :
 Если вы добавите ключевое слово  job  в  need:pipeline  , задание больше не будет отражать
состояние трубопровода. Поведение меняется на  need:pipeline:job  .
 только 
 / кроме  примечание  только  и , кроме , активно не разрабатываются.  правила  предпочтительнее
ключевое слово, чтобы контролировать, когда добавлять задания в конвейеры.
 Вы можете использовать  только  и , кроме , чтобы контролировать, когда добавлять задания в конвейеры.
 Используйте  только  для определения времени выполнения задания.
 Используйте , кроме , чтобы определить, когда задание  не выполняется.
 См. Укажите, когда задания выполняются только с   и , кроме  для более подробной информации и примеров.
 Только 
:ссылки  /  кроме:ссылки  Используйте только ключевые слова :ссылки  и  кроме:ссылки , чтобы контролировать, когда добавлять задания в
конвейер на основе имен ветвей или типов конвейеров. Только
 : ссылки  и , кроме: ссылки  активно не разрабатываются.  правил:если  является предпочтительным ключевым словом при использовании ссылок, регулярных выражений или переменных для управления
когда добавлять задания в пайплайны. 9характеристика-.*/  .
 Следующие ключевые слова:
  Значение   Описание 
  API 9081
  API 9159
  API 
 .
  ветвей  Когда ссылка Git для конвейера является ветвью.
  chat  Для конвейеров, созданных с помощью команды GitLab ChatOps.
  внешний  При использовании CI-сервисов, отличных от GitLab.
  external_pull_requests  При создании или обновлении внешнего запроса на вытягивание в GitHub (см. Конвейеры для внешних запросов на вытягивание).
  merge_requests  Для конвейеров, созданных при создании или обновлении запроса на слияние. Включает конвейеры запросов на слияние, конвейеры объединенных результатов и поезда слияния.
  конвейеры  Для многопроектных конвейеров, созданных с помощью API с  CI_JOB_TOKEN  или ключевым словом  триггера .
  pushs  Для конвейеров, запускаемых событием  git push , в том числе для ветвей и тегов.
  расписания  Для запланированных трубопроводов.
  теги  Когда ссылка Git для конвейера является тегом. 9стабильная ветвь.*$/
 - расписания   Дополнительные сведения  :
 Запланированные конвейеры выполняются в определенных ветвях, поэтому задания, настроенные только с : ветви  также запускать запланированные конвейеры. Добавить , кроме: расписания  для предотвращения заданий только с : ветви  от работы по запланированным конвейерам.
 Только   или , кроме , используемые без каких-либо других ключевых слов, эквивалентны только : ссылки  или  кроме: refs  . Например, следующие две конфигурации заданий имеют одинаковую
поведение:
 задание1:
  сценарий: эхо
  Только:
    - ветви
задание2:
  сценарий: эхо
  Только:
    ссылки:
      - ветви
 
 Если задание не использует  только ,  кроме  или  правила , тогда  только  устанавливается на  ветвей  и  тегов  по умолчанию.
 Например,  задание1  и  задание2  эквивалентны:
 задание1:
  скрипт: эхо "тест"
задание2:
  скрипт: эхо "тест"
  Только:
    - ветви
    - теги
 
 Только 
: переменные  /  кроме: переменные  Используйте ключевые слова  only:variables  или  exclude:variables  для управления добавлением заданий
в конвейер в зависимости от состояния переменных CI/CD.
  только: переменные  и  кроме: переменные  активно не разрабатываются.  правил:если  является предпочтительным ключевым словом при использовании ссылок, регулярных выражений или переменных для управления
когда добавлять задания в пайплайны.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Массив выражений переменных CI/CD.
  Пример только : переменные   :
 развертывание:
  скрипт: деплой промежуточной шапки
  Только:
    переменные:
      - $RELEASE == "постановка"
      - $ ПОСТАНОВКА
 
  Похожие темы  :
 Только : переменные  и , кроме: переменных  примеров.
 Только 
: изменения  /  кроме: изменения  Используйте ключевое слово  изменяет  с  только , чтобы запустить задание, или с , кроме , чтобы пропустить задание,
когда событие Git push изменяет файл.
 Использовать  изменений  в конвейерах со следующими ссылками:
  ответвлений 
  external_pull_requests 
  merge_requests  (см. дополнительные сведения об использовании 9Только 0816: изменения  с конвейерами мерж-реквестов)
 Только : изменения  и , за исключением: изменения  активно не разрабатываются.  правила: изменения  является предпочтительным ключевым словом при использовании измененных файлов для управления добавлением заданий в конвейеры.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Массив, включающий любое количество:
 Пути к файлам.
 Пути с подстановочными знаками для отдельных каталогов, например  path/to/directory/*  , или каталог
и все его подкаталоги, например  путь/к/каталогу/**/*  .
 Пути подстановочных знаков для всех
файлы с одинаковым или несколькими расширениями, например  *.md  или  путь/к/каталогу/*.{rb,py,sh}  .
См. документацию Ruby  fnmatch .
список поддерживаемого синтаксиса.
 Пути с подстановочными знаками к файлам в корневом каталоге или во всех каталогах, заключенные в двойные кавычки.
Например  "*.json"  или  "**/*.json"  .
  Пример только : изменения   :
 сборка докера:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  Только:
    ссылки:
      - ветви
    изменения:
      - Докерфайл
      - докер/скрипты/*
      - файлы докеров/**/*
      - more_scripts/*. {rb,py,sh}
      - "**/*.json"
 
  Дополнительные детали  :
  изменений  преобразуется в  true , если какой-либо из соответствующих файлов изменен (0816 ИЛИ операция ).
 Если вы используете ссылки, отличные от  ветвей  ,  external_pull_requests  или  merge_requests  ,  изменений  не может определить, является ли данный файл новым или старым, и всегда возвращает  true  .
 Если вы используете только : измените  с другими ссылками, задания игнорируют изменения и всегда выполняются.
 Если вы используете , кроме: изменения  с другими ссылками, задания игнорируют изменения и никогда не запускаются.
  Похожие темы  :
 Только : изменяет  и , кроме: изменяет примеры .
 Если вы используете  изменений  с разрешением мерж-реквестов только в случае успеха конвейера,
вы также должны использовать только :merge_requests  .
 Задания или конвейеры могут запускаться неожиданно только при использовании : изменения  .
 Только 
: kubernetes  /  кроме: kubernetes  Используйте только : kubernetes  или , кроме: kubernetes  для управления добавлением заданий в конвейер.
когда служба Kubernetes активна в проекте. Только
 : ссылки  и , кроме: ссылки  активно не разрабатываются. Использовать правила :если  с предопределенной переменной CI/CD  CI_KUBERNETES_ACTIVE  чтобы контролировать, добавляются ли задания в конвейер, когда служба Kubernetes активна в проекте.
  Тип ключевого слова  : Для конкретного задания. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Стратегия  kubernetes  принимает только ключевое слово  active .
  Пример только для : kubernetes   :
 развертывание:
  Только:
    Кубернетес: активен
 
 В этом примере задание  развертывания  запускается только тогда, когда служба Kubernetes активна. в проекте.
 страниц  Используйте  страниц , чтобы определить задание GitLab Pages, которое
загружает статический контент в GitLab. Затем контент публикуется как веб-сайт.
  Тип ключевого слова  : Имя задания.
  Пример  страниц   :
 страниц:
  этап: развертывание
  сценарий:
    - mkdir .public
    -cp -r * .public
    - mv .public общественность
  артефакты:
    пути:
      - общественный
  правила:
    - если: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  среда: производство
 
 В этом примере все файлы перемещаются из корня проекта в каталог  public/.
Обходной путь  .public  так  cp  также не копирует  public/  в себя в бесконечном цикле.
  Дополнительные сведения  :
 Необходимо:
 Помещать любой статический контент в каталог  public/.
 Определить артефакты   с путем к каталогу  public/.
 параллельно  Используйте  parallel  для параллельного запуска задания несколько раз в одном конвейере.
 Должно существовать несколько исполнителей или одно средство выполнения должно быть настроено для одновременного запуска нескольких заданий.
 Параллельные задания именуются последовательно от  job_name 1/N  до  job_name N/N  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Числовое значение от  2  до  50  .
  Пример  параллельного   :
 теста:
  сценарий: rspec
  параллельно: 5
 
 В этом примере создается 5 параллельно выполняемых заданий с именем  тест 1/5  –  тест 5/5  .
  Дополнительные сведения  :
 Каждое параллельное задание имеет  CI_NODE_INDEX  и  CI_NODE_TOTAL  предопределенный набор переменных CI/CD.
  Похожие темы  :
 Распараллеливайте большие задачи.
 параллель:матрица  История версий
 Представлено в GitLab 13.3.
 Стиль именования заданий был улучшен в GitLab 13.4.
 Используйте  parallel:matrix  для запуска задания несколько раз параллельно в одном конвейере,
но с разными значениями переменных для каждого экземпляра задания.
 Должно существовать несколько исполнителей или одно средство выполнения должно быть настроено для одновременного запуска нескольких заданий.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Массив хэшей переменных:
 В именах переменных могут использоваться только цифры, буквы и знаки подчеркивания (  _ ).
 Значения должны быть либо строкой, либо массивом строк.
 Количество перестановок не может превышать 50.
  Пример  parallel:matrix   :
 deploystacks:
  этап: развертывание
  сценарий:
    - бин/развернуть
  параллельно:
    матрица:
      - ПРОВАЙДЕР: aws
        КУЧА:
          - мониторинг
          - приложение1
          - приложение2
      - ПРОВАЙДЕР: ovh
        СТЕК: [мониторинг, резервное копирование, приложение]
      - ПРОВАЙДЕР: [gcp, vultr]
        СТЕК: [данные, обработка]
  среда: $PROVIDER/$STACK
 
 В этом примере создается 10 параллельных заданий  deploystacks , каждое из которых имеет разные значения
для  PROVIDER  и  STACK :
 deploystacks: [aws, мониторинг]
развертывание стеков: [aws, app1]
развертывание стеков: [aws, app2]
deploystacks: [ovh, мониторинг]
deploystacks: [ovh, резервная копия]
развертывание стеков: [ovh, приложение]
развертывание стеков: [gcp, данные]
deploystacks: [gcp, обработка]
развертывание стеков: [vultr, данные]
deploystacks: [vultr, обработка]
 
  Похожие темы :
 Запустите одномерную матрицу параллельных заданий.
 Запустите матрицу запущенных параллельных заданий.
 Выберите разные теги бегуна для каждого параллельного матричного задания.
 выпуск  Представлено в GitLab 13.2.
 Используйте версию   для создания версии.
 Задание выпуска должно иметь доступ к  Release-cli  ,
который должен быть в  $PATH  .
 Если вы используете исполнитель Docker,
вы можете использовать этот образ из реестра контейнеров GitLab:  register.gitlab.com/gitlab-org/release-cli:latest 
 Если вы используете исполняющую программу Shell или аналогичную,
установить  релиз-кли  на сервер, где прописан раннер.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  : Подключи выпуска  :
  tag_name 
  tag_message  (необязательно)
  имя  (опционально)
  описание 
  №  (дополнительно)
  вех  (опционально)
  Release_at  (опционально)
  assets:links  (необязательно)
  Пример ключевого слова  выпуска   :
 release_job:
  этап: релиз
  образ:Registry. gitlab.com/gitlab-org/release-cli:latest
  правила:
    - if: $CI_COMMIT_TAG # Запускать это задание, когда тег создается вручную
  сценарий:
    - echo "Выполняется задание выпуска."
  выпускать:
    имя_тега: $CI_COMMIT_TAG
    имя: 'Выпустить $CI_COMMIT_TAG'
    description: 'Релиз создан с помощью Release-cli.'
 
 В этом примере создается релиз:
 При нажатии тега Git.
 При добавлении тега Git в пользовательский интерфейс в разделе  Репозиторий > Теги  .
  Дополнительная информация  :
 Все задания выпуска, за исключением заданий триггера, должны включать ключевое слово  сценария . Релиз
job может использовать вывод команд сценария. Если вам не нужен скрипт, вы можете использовать заполнитель: скрипт
:
  - эхо "выпустить задание"
 
 Существует проблема, связанная с удалением этого требования.
 Раздел  выпуска  выполняется после ключевого слова  сценария  и перед  after_script  .
 Релиз создается только в случае успешного выполнения основного сценария задания.
 Если выпуск уже существует, он не обновляется, и задание с ключевым словом  выпуска  завершается сбоем.
  Похожие темы  :
 Пример CI/CD ключевого слова  выпуска .
 Создавайте несколько выпусков в одном конвейере.
 Используйте пользовательский центр сертификации SSL CA.
 Выпуск 
: имя_тега  Обязательно. Тег Git для релиза.
 Если тег еще не существует в проекте, он создается одновременно с выпуском.
Новые теги используют SHA, связанный с конвейером.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Имя тега.
 Поддерживаются переменные CI/CD.
  Пример  release:tag_name   :
 Для создания релиза при добавлении в проект нового тега:
 Используйте переменную  $CI_COMMIT_TAG  CI/CD 7 в качестве тега 1_ .
 Использовать правила : если только  или : теги  для настройки
задание запускать только для новых тегов.
 работа:
  script: echo "Выполняется задание выпуска для нового тега."
  выпускать:
    имя_тега: $CI_COMMIT_TAG
    description: 'Описание релиза'
  правила:
    - если: $CI_COMMIT_TAG
 
 Чтобы одновременно создать релиз и новый тег, ваш  управляет только  или   если , а не , настройте задание так, чтобы оно выполнялось только для новых тегов. Пример семантической версии:
 job:
  script: echo "Запуск задания выпуска и создание нового тега."
  выпускать:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Описание релиза'
  правила:
    - если: $CI_PIPELINE_SOURCE == "расписание"
 
 Выпуск 
: tag_message  Представлено в GitLab 15.3. Поддерживается  Release-Cli  v0.12.0 или более поздней версии.
 Если тег не существует, вновь созданный тег аннотируется сообщением, указанным в  tag_message  . Если он опущен, создается упрощенный тег.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Текстовая строка.
  Пример  release:tag_message   :
 release_job:
    этап: релиз
    выпускать:
      имя_тега: $CI_COMMIT_TAG
      description: 'Описание релиза'
      tag_message: 'Аннотированное сообщение тега'
 
 Версия 
: имя  Название выпуска. Если он опущен, он заполняется значением выпуска : tag_name  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Текстовая строка.
  Пример  релиз:имя   :
 релиз_работа:
    этап: релиз
    выпускать:
      имя: 'Выпустить $CI_COMMIT_TAG'
 
 Выпуск 
: описание  Подробное описание релиза.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Строка с длинным описанием.
 Путь к файлу, содержащему описание. Представлено в GitLab 13.7. Расположение файла должно быть относительно каталога проекта (  $CI_PROJECT_DIR  ).
 Если файл является символической ссылкой, он должен быть в  $CI_PROJECT_DIR  .
  ./path/to/file  и имя файла не могут содержать пробелы.
  Пример выпуска : описание   :
 задание:
  выпускать:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    описание: './path/to/CHANGELOG.md'
 
 Выпуск 
: ссылка   ref  для выпуска, если выпуск : имя_тега  еще не существует.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 SHA фиксации, другое имя тега или имя ветки.
 Выпуск 
: вехи  Название каждой вехи, с которой связан выпуск.
 Выпуск 
:released_at  Дата и время готовности релиза.
  Возможные значения  :
 Дата, заключенная в кавычки и выраженная в формате ISO 8601.
  Пример выпуска :released_at   :
 Release_at: '2021-03-15T08:00:00Z'
 
  Дополнительные сведения  :
 Если не указано, используются текущие дата и время.
 выпуск:активы:ссылки  Представлено в GitLab 13.12.
 Используйте  release:assets:links , чтобы включить ссылки на активы в выпуск.
 Требуется  Release-Cli  версии v0.4.0 или выше.
  Пример выпуска : активы: ссылки   :
 активы:
  ссылки:
    - имя: 'актив1'
      URL-адрес: https://example. com/assets/1.
    - имя: 'актив2'
      URL-адрес: «https://example.com/assets/2»
      путь к файлу: '/pretty/url/1' # необязательно
      link_type: 'другое' # необязательно
 
 группа_ресурсов  Представлено в GitLab 12.7.
 Используйте  resource_group  для создания группы ресурсов,
гарантирует, что задание является взаимоисключающим для разных конвейеров одного и того же проекта.
 Например, если несколько заданий, принадлежащих к одной группе ресурсов, одновременно поставлены в очередь,
запускается только одно из заданий. Другие задания ждут, пока  resource_group  не освободится.
 Группы ресурсов ведут себя подобно семафорам в других языках программирования.
 Для каждой среды можно определить несколько групп ресурсов. Например,
при развертывании на физические устройства у вас может быть несколько физических устройств. Каждое устройство
может быть развернут, но только одно развертывание может произойти на устройство в любой момент времени.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы : только буквы, цифры,  - ,  _ ,  /,  $ ,  {, } , , , .  и пробелы.
Он не может начинаться или заканчиваться на /. Поддерживаются переменные CI/CD.
  Пример  resource_group   :
 развертывание в рабочей среде:
  сценарий: развернуть
  группа_ресурсов: производство
 
 В этом примере два задания  по развертыванию в рабочей среде  в двух отдельных конвейерах никогда не могут выполняться одновременно. Как результат,
вы можете гарантировать, что одновременные развертывания никогда не произойдут в производственной среде.
  Похожие темы  :
 Контроль параллелизма на уровне конвейера с конвейерами между проектами и родителем-потомком.
 повторить попытку  Используйте  повторных попыток , чтобы настроить количество повторных попыток задания в случае сбоя.
Если не определено, по умолчанию  0  и задания не повторяются.
 При сбое задания оно обрабатывается еще два раза до тех пор, пока оно не завершится успешно или
достигает максимального количества повторных попыток.
 По умолчанию все типы сбоев вызывают повторную попытку задания. Использовать  повтор: когда  чтобы выбрать, при каких ошибках повторить попытку.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
  0  (по умолчанию),  1  или  2  .
  Пример повторной попытки    :
 теста:
  сценарий: rspec
  повторить: 2
 
 повтор: когда  Используйте повторную попытку : когда  с повторной попыткой : макс. , чтобы повторить задания только для определенных случаев сбоя.  retry:max  — максимальное количество повторных попыток, например  retry  , и может быть  0 ,  1  или  2 .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входы  :
 Один тип отказа или массив из одного или нескольких типов отказа:
  всегда  : Повторить попытку при любом сбое (по умолчанию).
  unknown_failure  : повторите попытку, если причина сбоя неизвестна.
  script_failure  : повторите попытку после сбоя сценария.
  api_failure  : повторите попытку при сбое API.
  stick_or_timeout_failure  : повторите попытку, если задание зависло или истекло время ожидания.
  runner_system_failure  : повторите попытку, если произошел сбой системы бегуна (например, сбой настройки задания).
  runner_unsupported  : повторите попытку, если бегун не поддерживается.
  stale_schedule  : повторите попытку, если отложенное задание не может быть выполнено.
  job_execution_timeout  : повторите попытку, если сценарий превысил максимальное время выполнения, установленное для задания.
  archived_failure  : повторите попытку, если задание заархивировано и не может быть запущено.
  unmet_prerequisites  : повторите попытку, если заданию не удалось выполнить предварительные задачи.
  scheduler_failure  : повторите попытку, если планировщику не удалось назначить задание исполнителю.
  data_integrity_failure  : повторите попытку, если обнаружена проблема структурной целостности.
  Пример повторной попытки : когда   (тип одиночного сбоя):
 тест:
  сценарий: rspec
  повторить:
    макс: 2
    когда: runner_system_failure
 
 В случае сбоя, отличного от сбоя системы бегуна, задание не повторяется.
  Пример повторной попытки : когда   (массив типов ошибок):
 тест:
  сценарий: rspec
  повторить:
    макс: 2
    когда:
      - runner_system_failure
      - застрял_or_timeout_failure
 
  Связанные темы  :
 Можно указать количество повторных попыток для определенных этапов выполнения задания.
используя переменные.
 правила  Представлено в GitLab 12.3.
 Используйте правила   для включения или исключения заданий в конвейерах.
 Правила оцениваются при создании конвейера и оцениваются  в порядке  до первого матча. Когда совпадение найдено, задание либо включается, либо исключается из конвейера.
в зависимости от конфигурации.
 Нельзя использовать переменные dotenv, созданные в сценариях заданий, в правилах, так как правила оцениваются перед выполнением любых заданий.
  правила  заменяют только /кроме  и не могут использоваться вместе
на той же работе. Если вы настроите одно задание на использование обоих ключевых слов, GitLab вернет
ключ  нельзя использовать с ошибкой правил .
  rules  accepts an array of rules defined with:
  if 
  changes 
  exists 
  allow_failure 
  variables 
  когда 
 Вы можете комбинировать несколько ключевых слов для сложных правил.
 Задание добавлено в конвейер:
 Если  if  ,  изменяет  или  существует  соответствует правилу, а также имеет  когда: on_success  (по умолчанию),  когда: задержано  или  когда: всегда  .
 Если достигнуто правило, равное только , когда: on_success , , когда: задержано , или , когда: всегда  .
 Задание не добавлено в конвейер:
 Если ни одно правило не соответствует.
 Если правило соответствует и имеет  когда: никогда  .
 Вы можете использовать теги  !reference  для повторного использования  правил  конфигурации
на разных работах.
 правил:если  Используйте правила : условия if , чтобы указать, когда добавлять задание в конвейер:
 Если утверждение  if  истинно, добавьте задание в конвейер.
 Если утверждение  if  верно, но оно сочетается с , когда: никогда  , не добавлять задание в конвейер.
 Если нет , если утверждения  верны, не добавляйте задание в конвейер.
 , если  предложений оцениваются на основе значений предопределенных переменных CI/CD
или пользовательские переменные CI/CD.
  Тип ключевого слова  : зависит от задания и конвейера. Вы можете использовать его как часть работы
для настройки поведения задания или с помощью 9особенность/
 когда: вручную
 allow_failure: правда
 – если: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME 
  Дополнительные сведения  :
 Если правило соответствует и не имеет , когда определено , правило использует , когда  определено для задания, которое по умолчанию равно  on_success , если не определено.
 В GitLab 14.5 и более ранних версиях вы можете определить , когда  один раз для правила или один раз на уровне задания,
что относится ко всем правилам. нельзя смешивать , когда  на уровне задания с , когда  в правилах.
 В GitLab 14.6 и более поздних версиях вы можете смешивать , когда  на уровне задания, с , когда  в правилах. , когда конфигурация  в правилах   имеет приоритет над , когда  на уровне задания.
 В отличие от переменных в сценарии   разделы, переменные в выражениях правил всегда имеют формат  $VARIABLE  . Можно использовать правила :если  с  включает  для условного включения других файлов конфигурации.
 Переменные CI/CD в правой части выражений  =~  и  !~  оцениваются как регулярные выражения.
  Похожие темы  :
 Общие  если  выражений для  правила  .
 Избегайте дублирования конвейеров.
 Используйте правила   для запуска конвейеров мерж-реквестов.
 правил:изменений  Используйте правила : изменения , чтобы указать, когда добавлять задание в конвейер, проверяя наличие изменений
к конкретным файлам.
 предостережение Вы должны использовать правила : изменения  только с  ответвлениями  или  мерж-реквестами  .
Вы можете использовать правила : изменяет  с другими типами конвейеров, но правила : изменяет  всегда
оценивается как true, если нет события Git  push . Конвейеры тегов, запланированные конвейеры, ручные конвейеры,
и так далее , а не  имеют связанное с ними событие Git  push . Правила : изменение задания   всегда добавляется  к этим конвейерам, если нет , если  ограничивает задание до
конвейеры ответвлений или мерж-реквестов.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Массив, включающий любое количество:
 Пути к файлам. В GitLab 13.6 и более поздних версиях пути к файлам могут включать переменные.
Массив пути к файлу также может быть в  правила:изменения:пути  .
 Подстановочные пути для: Отдельные каталоги, например  путь/к/каталогу/*  .
 Каталог и все его подкаталоги, например  путь/к/каталогу/**/*  .
 Пути подстановочных знаков для всех файлов
с одним или несколькими расширениями, например  *.md  или  путь/к/каталогу/*.{rb,py,sh}  .
См. документацию Ruby  fnmatch .
список поддерживаемого синтаксиса.
 Пути с подстановочными знаками к файлам в корневом каталоге или во всех каталогах, заключенные в двойные кавычки.
Например,  "*. json"  или  "**/*.json"  .
  Пример правил : изменения   :
 сборка докера:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  правила:
    - если: $CI_PIPELINE_SOURCE == "merge_request_event"
      изменения:
        - Докерфайл
      когда: вручную
      allow_failure: правда
 
 Если конвейер является конвейером запросов на слияние, отметьте  Dockerfile  для изменений.
 Если  Dockerfile  изменился, добавьте задание в конвейер как ручное задание, а конвейер
продолжает работать, даже если задание не запущено (  allow_failure: true  ).
 Если  Dockerfile  не изменился, не добавляйте задание ни в один конвейер (так же, как , когда: никогда  ).
  rules:changes:paths  совпадает с  rules:changes  без
любые подразделы.
  Дополнительная информация  :
 Правила : изменяет  работает так же, как и  только: изменяет  и  кроме: изменяет  .
 Вы можете использовать , когда: никогда не  для реализации правила, аналогичного , за исключением:changes  .
  изменяет  преобразуется в  true , если изменяется любой из соответствующих файлов (операция  ИЛИ ).
  Похожие темы  :
 Задания или конвейеры могут запускаться неожиданно при использовании  правила: изменения  .
 правила:изменения:пути  Представлено в GitLab 15.2.
 Используйте правила : изменяет , чтобы указать, что задание добавляется в конвейер, только если оно указано
файлы изменены, и используйте  rules:changes:paths  для указания файлов.
  правила:изменения:пути  аналогично использованию  правила:изменения  без
любые подразделы. Все дополнительные детали и сопутствующие темы остаются прежними.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Массив путей к файлам. В GitLab 13.6 и более поздних версиях пути к файлам могут включать переменные.
  Пример  rules:changes:paths   :
 docker-build-1:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  правила:
    - если: $CI_PIPELINE_SOURCE == "merge_request_event"
      изменения:
        - Докерфайл
докер-сборка-2:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  правила:
    - если: $CI_PIPELINE_SOURCE == "merge_request_event"
      изменения:
        пути:
          - Докерфайл
 
 В этом примере оба задания ведут себя одинаково.
 правила:изменения:сравнить_с  История версий
 Представлен в GitLab 15.3 с флагом  ci_rules_changes_compare  . Включено по умолчанию.
 Обычно доступно в GitLab 15. 5. Флаг функции  ci_rules_changes_compare  удален.
 Используйте  rules:changes:compare_to , чтобы указать, с какой ссылкой сравнивать изменения в файлах
перечислено под  правила:изменения:пути  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть задания, и он должен быть объединен с  rules:changes:paths  .
  Возможные входы  :
 Имя ветки, например  main  ,  branch2  или  refs/heads/branch2  .
 Имя тега, например  tag1  или  refs/tags/tag1  .
 SHA фиксации, например  2fg31ga14b  .
  Пример  rules:changes:compare_to   :
 docker build:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  правила:
    - если: $CI_PIPELINE_SOURCE == "merge_request_event"
      изменения:
        пути:
          - Докерфайл
        compare_to: 'refs/heads/branch2'
 
 В этом примере задание  docker build  включается только при изменении файла  Dockerfile . относительно  refs/heads/branch2 , а источником конвейера является событие запроса на слияние.
 правил:существует  Представлено в GitLab 12.4.
 Используйте  exists  для запуска задания, когда в репозитории существуют определенные файлы.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Массив путей к файлам. Пути относятся к каталогу проекта (  $CI_PROJECT_DIR  )
и не может напрямую ссылаться за его пределами. Пути к файлам могут использовать шаблоны глобусов.
  Пример правил : существует   :
 задание:
  скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  правила:
    - существуют:
        - Докерфайл
 
  Задание  запускается, если  Dockerfile  существует где-либо в репозитории.
  Дополнительные сведения  :
 Шаблоны Glob интерпретируются с помощью Ruby  File.fnmatch  с флагами  File::FNM_PATHNAME | Файл::FNM_DOTMATCH | Файл::FNM_EXTGLOB  .
 Из соображений производительности GitLab соответствует максимум 10 000  существующих  шаблонов или
пути к файлам. После 10 000-й проверки правила с шаблонными глобусами всегда совпадают.
Другими словами,  существует  всегда сообщает  верно  если более 10000 проверок
бегать. Репозитории с менее чем 10 000 файлов могут быть затронуты, если  существует  правила проверены более 10000 раз.
  существует  преобразуется в  true , если любой из перечисленных файлов найден (0816 ИЛИ операция ).
 правила:allow_failure  Представлено в GitLab 12.8.
 Используйте  allow_failure: true  в правилах  , чтобы разрешить сбой задания
без остановки трубопровода.
 Вы также можете использовать  allow_failure: true  с ручным заданием. Трубопровод продолжается
работает, не дожидаясь результата ручного задания.  allow_failure: ложь  в сочетании с , когда: вручную  в правилах заставляет конвейер ждать руководства
задание для запуска, прежде чем продолжить.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  истина  или  ложь  . По умолчанию  false , если не определено.
  Пример правил :allow_failure   :
 задание:
  script: echo "Привет, Правила!"
  правила:
    - если: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
      когда: вручную
      allow_failure: правда
 
 Если правило соответствует, то задание выполняется вручную с  allow_failure: true  .
  Дополнительные сведения  :
 Правила уровня  rules:allow_failure  переопределяют уровень задания  allow_failure  ,
и применяется только тогда, когда определенное правило запускает задание.
 правила:переменные  История версий
 Представлено в GitLab 13.7.
 Флаг функции удален в GitLab 13.10.
 Используйте переменные   в правилах   для определения переменных для конкретных условий.
  Тип ключевого слова  : Для конкретного задания. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Хэш переменных в формате  ИМЯ-ПЕРЕМЕННОЙ: значение  .
  Пример правил : переменные   :
 задание:
  переменные:
    DEPLOY_VARIABLE: «развертывание по умолчанию»
  правила:
    - если: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      переменные: # Переопределить DEPLOY_VARIABLE определено
        DEPLOY_VARIABLE: "deploy-production" # на уровне задания. 
    - если: $CI_COMMIT_REF_NAME =~ /feature/
      переменные:
        IS_A_FEATURE: "true" # Определить новую переменную.
  сценарий:
    - echo "Запустить скрипт с $DEPLOY_VARIABLE в качестве аргумента"
    - echo "Запустить другой скрипт, если $IS_A_FEATURE существует"
 
 скрипт  Используйте сценарий  , чтобы указать команды для выполнения бегуном.
 Для всех заданий, кроме триггерных заданий, требуется ключевое слово сценария  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Массив, включающий:
 Однострочные команды.
 Длинные команды разбиты на несколько строк.
 Якоря YAML.
 Поддерживаются переменные CI/CD.
  Пример сценария    :
 задание 1:
  скрипт: "комплект exec rspec"
задание2:
  сценарий:
    - имя-а
    - пакет exec rspec
 
  Дополнительная информация :
 Когда вы используете эти специальные символы в  Script , вы должны использовать отдельные цитаты ( ') или двойные цитаты ( ").
 .
 Вы можете игнорировать ненулевые коды выхода
 Используйте цветовые коды с  скрипт  для облегчения просмотра журналов заданий.
 Создание настраиваемых складных разделов
для упрощения вывода журнала заданий.
 секретов  Представлено в GitLab 13.4.
 Используйте секреты  , чтобы указать секреты CI/CD для:
 Получить от внешнего поставщика секретов.
 Сделать доступными в задании переменные CI/CD
(  тип файла  по умолчанию).
 Это ключевое слово должно использоваться с  секретами: хранилище  .
 секретов: хранилище  Представлено в GitLab 13.4 и GitLab Runner 13.4.
 Используйте  secrets:vault  для указания секретов, предоставляемых хранилищем HashiCorp.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  engine:name  : Название механизма секретов.
  двигатель:путь  : Путь к механизму секретов.
  путь  : Путь к секрету.
  поле  : Имя поля, в котором хранится пароль.
  Пример  секретов: хранилище   :
 Чтобы указать все детали явно и использовать механизм секретов КВ-В2:
 задание:
  секреты:
    DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD
      vault: # Переводится как секрет: `ops/data/production/db`, поле: `пароль`
        двигатель:
          название: кв-в2
          путь: опс
        путь: производство/дб
        поле: пароль
 
 Вы можете сократить этот синтаксис. С коротким синтаксисом  двигатель:имя  и  двигатель:путь  оба по умолчанию  kv-v2  :
 задание:
  секреты:
    DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD
      vault: production/db/password # Переводит в secret: `kv-v2/data/production/db`, поле: `password`
 
 Чтобы указать пользовательский путь механизма секретов в кратком синтаксисе, добавьте суффикс, начинающийся с  @  :
 задание:
  секреты:
    DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD
      vault: production/db/password@ops # Переводит в секрет: `ops/data/production/db`, поле: `пароль`
 
 секретов:файл  Представлен в GitLab 14. 1 и GitLab Runner 14.1.
 Используйте  secrets:file  для настройки сохранения секрета как  файл  или  переменная  тип переменная CI/CD
 По умолчанию секрет передается заданию как  файл  тип переменной CI/CD. Значение
секрет хранится в файле, а переменная содержит путь к файлу.
 Если ваше программное обеспечение не может использовать переменные типа  файла  CI/CD, установите файл : false  для хранения
секретное значение непосредственно в переменной.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
  true  (по умолчанию) или  false  .
  Пример  секретов: файл   :
 задание:
  секреты:
    DATABASE_PASSWORD:
      хранилище: production/db/password@ops
      файл: ложь
 
  Дополнительные сведения  :
 Ключевое слово  файла  является настройкой для переменной CI/CD и должно быть вложено в
имя переменной CI/CD, не в разделе  хранилища .
 услуги  Используйте службы  , чтобы указать дополнительный образ Docker для запуска сценариев.  услуги  изображение связано
к изображению, указанному в ключевом слове  image .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : имя образа службы, включая путь реестра, если необходимо, в одном из следующих форматов:
    (То же, что и при использовании    с последним тегом  )
  : 
  @ 
 Переменные CI/CD поддерживаются, но не для псевдонима   .
  Пример служб    :
 по умолчанию:
  изображение:
    имя: рубин: 2,6
    точка входа: ["/bin/bash"]
  Сервисы:
    - имя: my-postgres:11. 7
      псевдоним: db-postgres
      точка входа: ["/usr/local/bin/db-postgres"]
      команда: ["старт"]
  до_скрипта:
    - пакетная установка
тест:
  сценарий:
    - пакетная спецификация рейка exec
 
 В этом примере задание запускает контейнер Ruby. Затем из этого контейнера запускается задание
другой контейнер, на котором работает PostgreSQL. Затем задание запускает сценарии
в этом контейнере.
  Похожие темы  :
 Доступные настройки для служб   .
 Определите службы   в файле  .gitlab-ci.yml .
 Запускайте задания CI/CD в контейнерах Docker.
 Используйте Docker для создания образов Docker.
 служба: pull_policy  История версий
 Представлен в GitLab 15.1 с флагом  ci_docker_image_pull_policy  . Отключено по умолчанию.
 Включено на GitLab.com и самостоятельно управляется в GitLab 15. 2.
 Обычно доступно в GitLab 15.4. Флаг функции  ci_docker_image_pull_policy  удален.
 Требуется GitLab Runner 15.1 или новее.
 Политика извлечения, используемая исполнителем для получения образа Docker.  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть задания или в разделе  по умолчанию .
  Возможные входные данные  :
 Одна политика извлечения или несколько политик извлечения в массиве.
Может быть  всегда  ,  если нет  , или  никогда  .
  Примеры  service:pull_policy   :
 job1:
  script: echo "Единая политика извлечения".
  Сервисы:
    - имя: postgres:11.6
      pull_policy: если нет
задание2:
  script: echo "Несколько политик извлечения".
  Сервисы:
    - имя: postgres:11.6
      pull_policy: [всегда, если нет]
 
  Дополнительные сведения  :
 Если средство выполнения не поддерживает заданную политику извлечения, задание завершается с ошибкой, подобной следующей:  ОШИБКА: Сбой задания (сбой системы): настроенные политики PullPolicies ([всегда]) не разрешены AllowedPullPolicies ([никогда])  .
  Похожие темы  :
 Запускайте задания CI/CD в контейнерах Docker.
 Как работают политики вытягивания бегунов.
 Использование нескольких политик вытягивания.
 этап  Используйте  stage , чтобы определить, на каком этапе выполняется задание.  стадия  может выполняться параллельно (см.  Дополнительные сведения ).
 Если этап   не определен, задание по умолчанию использует этап тестирования  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  : Массив, включающий любое количество имен этапов. Сценические имена могут быть:
 Стадии по умолчанию.
 Определяемые пользователем этапы.
  Пример столика    :
 столика:
  - строить
  - тест
  - развертывать
задание1:
  этап: сборка
  сценарий:
    - echo "Это задание компилирует код. "
задание2:
  этап: тест
  сценарий:
    - echo "Это задание проверяет скомпилированный код. Оно запускается после завершения этапа сборки."
задание3:
  сценарий:
    - echo "Это задание также выполняется на этапе тестирования".
задание4:
  этап: развертывание
  сценарий:
    - echo "Это задание развертывает код. Оно запускается после завершения этапа тестирования."
  среда: производство
 
  Дополнительные сведения  :
 Задания могут выполняться параллельно, если они выполняются на разных исполнителях.
 Если у вас есть только один бегун, задания могут выполняться параллельно, если бегун  одновременная настройка  больше, чем  1  .
 этап: .pre  Представлено в GitLab 12.4.
 Используйте этап  .pre , чтобы запустить задание в начале конвейера.  .до  всегда первый этап в конвейере. Определяемые пользователем этапы выполняются через  .до  . Вам не нужно определять  .pre  в  этапах  .
 Если конвейер содержит только задания на этапах  .pre  или  .post , он не запускается.
На другом этапе должна быть хотя бы одна другая работа.
  Тип ключевого слова : Вы можете использовать его только с ключевым словом задания  stage .
  Пример стадии : .pre   :
 стадии:
  - строить
  - тест
задание1:
  этап: сборка
  сценарий:
    - echo "Это задание выполняется на этапе сборки."
Первая работа:
  этап: .pre
  сценарий:
    - echo "Это задание выполняется на этапе .pre перед всеми остальными этапами."
задание2:
  этап: тест
  сценарий:
    - echo "Это задание выполняется на этапе тестирования."
 
 этап: .post  Представлено в GitLab 12.4.
 Используйте этап  .post , чтобы запустить задание в конце конвейера.  .пост  всегда является последней стадией конвейера. Определяемые пользователем этапы выполняются до  .post  .
Вам не нужно определять  .post  в  этапах  .
 Если конвейер содержит только задания на этапах  .pre  или  .post , он не запускается.
На другом этапе должна быть хотя бы одна другая работа.
  Тип ключевого слова : Вы можете использовать его только с ключевым словом задания  stage .
  Пример стадии : .post   :
 стадии:
  - строить
  - тест
задание1:
  этап: сборка
  сценарий:
    - echo "Это задание выполняется на этапе сборки."
Последнее место работы:
  этап: .post
  сценарий:
    - echo "Это задание выполняется на этапе .post после всех остальных этапов."
задание2:
  этап: тест
  сценарий:
    - echo "Это задание выполняется на этапе тестирования."
 
 теги  История версий
 Ограничение в 50 тегов на задание включено на GitLab. com в GitLab 14.3.
 Ограничение в 50 тегов на задание включено для самостоятельного управления в GitLab 14.3.
 Используйте теги   для выбора конкретного бегуна из списка всех бегунов, которые
доступны для проекта.
 При регистрации бегуна можно указать теги бегуна, для
пример  ruby  ,  postgres  или  development  . Чтобы взяться за дело и запустить его, бегун должен
быть присвоен каждому тегу, указанному в задании.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  :
 Массив имен тегов.
 Переменные CI/CD поддерживаются
в GitLab 14.1 и выше.
  Пример тегов    :
 задание:
  теги:
    - Рубин
    - постгрес
 
 В этом примере только полозья с  и  и  рубинами  и  тегов postgres  могут выполнять задание.
  Дополнительные сведения  :
 В GitLab 14.3 и более поздних версиях
количество тегов должно быть меньше  50  .
  Похожие темы  :
 Используйте теги, чтобы контролировать, какие задания может выполнять бегун.
 Выберите разные теги бегуна для каждого параллельного матричного задания.
 тайм-аут  Представлено в GitLab 12.3.
 Использовать тайм-аут  , чтобы настроить тайм-аут для определенного задания. Если работа длится дольше
чем тайм-аут, задание не выполняется.
 Время ожидания на уровне задания может превышать время ожидания на уровне проекта.
но не может быть больше тайм-аута бегуна.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы или в  раздел по умолчанию .
  Возможные входные данные  : Период времени, записанный на естественном языке. Например, все они эквивалентны:
  3600 секунд 
  60 минут 
  один час 
  скрипт: build.sh
 тайм-аут: 3 часа 30 минут
тест:
 сценарий: rspec
 тайм-аут: 3 часа 30 минут 
 триггер  Используйте триггер  , чтобы объявить задание «триггерным заданием», которое запускает
нисходящий трубопровод:
 Многопроектный пайплайн.
 Дочерний конвейер.
 Триггерные задания могут использовать только ограниченный набор ключевых слов конфигурации GitLab CI/CD.
Ключевые слова, доступные для использования в триггерных заданиях:
  триггер  .
  этап  .
  разрешить_сбой  .
  правила  .
  только  и  кроме .
  при  (только со значением  on_success  ,  on_failure  или  всегда ).
  расширяет  .
  нужен  , но не  нужен: проект  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Для конвейеров с несколькими проектами — путь к нижестоящему проекту. Поддерживаются переменные CI/CD
в GitLab 15.3 и более поздних версиях, но не сохраняемые переменные уровня задания.
В качестве альтернативы используйте `trigger:project.
 Для дочерних конвейеров используйте 9Триггер 0816: включить .
  Пример триггера    :
 триггер-многопроектный-конвейер:
  триггер: моя группа/мой проект
 
  Дополнительные сведения  :
 Вы не можете использовать API для запуска , когда:ручной запуск  заданий.
 В GitLab 13.5 и более поздних версиях вы
можно использовать , когда: вручную  в том же задании, что и , запускающий  . В GitLab 13.4 и
ранее их совместное использование вызывало ошибку  jobs:#{job-name}, когда должно быть on_success, on_failure или всегда  .
 Ручные переменные конвейера
и запланированные переменные конвейера
по умолчанию не передаются нижестоящим конвейерам. Использовать триггер: вперед
для пересылки этих переменных в нижестоящие конвейеры.
 Сохраняемые переменные уровня задания
недоступны в триггерных заданиях.
  Похожие темы  :
 Примеры конфигурации многопроектного пайплайна.
 Чтобы запустить конвейер для определенной ветки, тега или фиксации, вы можете использовать токен триггера.
для аутентификации с помощью API триггеров конвейера.
Токен триггера отличается от  запускает ключевое слово .
 Триггер 
: включить  Используйте триггер : включите , чтобы объявить, что задание является «триггерным заданием», которое запускает
дочерний трубопровод.
 Используйте  trigger:include:artifact  для запуска динамического дочернего конвейера.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входные данные  :
 Путь к файлу конфигурации дочернего конвейера.
  Пример триггера : включить   :
 триггер-дочерний конвейер:
  курок:
    включают: путь/к/child-pipeline.gitlab-ci.yml
 
  Похожие темы  :
 Примеры конфигурации дочернего конвейера.
 Триггер 
: проект  Используйте триггер : проект , чтобы объявить задание «триггерным заданием», которое запускает
многопроектный пайплайн.
 По умолчанию многопроектный конвейер запускается для ветви по умолчанию. Используйте  триггер:ветвь  чтобы указать другую ветвь.
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его только как часть работы.
  Возможные входы  :
 Путь к нижестоящему проекту. Поддерживаются переменные CI/CD
в GitLab 15.3 и более поздних версиях, но не сохраняемые переменные уровня задания.
  Пример триггера : проект   :
 триггер-многопроектный-конвейер:
  курок:
    проект: моя группа/мой проект
 
  Пример триггера : проект  для другой ветки  :
 триггер-мультипроект-конвейер:
  курок:
    проект: моя группа/мой проект
    отрасль: разработка
 
  Похожие темы  :
 Примеры конфигурации многопроектного пайплайна.
 Чтобы запустить конвейер для определенной ветки, тега или фиксации, вы также можете использовать токен триггера.
для аутентификации с помощью API триггеров конвейера.
Токен триггера отличается от  запускает ключевое слово .
 триггер:стратегия  Используйте  триггер: стратегия , чтобы заставить задание  триггера  ожидать завершения нисходящего конвейера
до того, как он будет помечен как , успех .
 Это поведение отличается от поведения по умолчанию, которое заключается в том, что задание триггера   помечается как  успех , как только нижестоящий конвейер будет создан.
 Этот параметр делает выполнение конвейера линейным, а не параллельным.
  Пример триггера : стратегия   :
 trigger_job:
  курок:
    включают: путь/к/child-pipeline.yml
    стратегия: зависеть
 
 В этом примере задания из последующих стадий ожидают запуска запущенного конвейера.
успешно завершить перед началом.
  Дополнительная информация  :
 Дополнительные ручные задания в нисходящем конвейере
не влияют на состояние нижестоящего конвейера или вышестоящего триггерного задания.
Нисходящий конвейер может успешно завершиться без выполнения каких-либо дополнительных ручных заданий.
 Блокирование ручных заданий в нисходящем конвейере
должен выполняться до того, как задание триггера будет помечено как успешное или неудачное. Триггерная работа
показывает  в ожидании  (), если статус нижестоящего конвейера  Ожидание ручного действия  () из-за ручных заданий. По умолчанию,
задания на более поздних этапах не запускаются до тех пор, пока не завершится задание триггера.
 триггер:вперед  История версий
 Представлен в GitLab 14.9 с флагом 9.0816 ci_trigger_forward_variables  . Отключено по умолчанию.
 Включено на GitLab.com и самоуправляемо в GitLab 14.10.
 Общедоступно в GitLab 15.1. Флаг функции  ci_trigger_forward_variables  удален.
 Используйте  trigger:forward , чтобы указать, что пересылать в нижестоящий конвейер. Вы можете контролировать
что пересылается в оба родительско-дочерних конвейера
и многопроектные пайплайны.
  Возможные входы  :
  yaml_variables  :  true  (по умолчанию) или  false  . Когда  истинно  , переменные определены
в задании триггера передаются нижестоящим конвейерам.
  pipe_variables  :  true  или  false  (по умолчанию). Когда  true  , ручные переменные конвейера и запланированные переменные конвейера
передаются в нисходящие трубопроводы.
  Пример  триггера:вперед   :
 Запустите этот конвейер вручную с помощью
переменная CI/CD  MYVAR = мое значение  :
 переменные: # переменные по умолчанию для каждого задания
  ВАР: значение
# Поведение по умолчанию:
# - VAR передается потомку
# - MYVAR не передается потомку
ребенок1:
  курок:
    включают: .child-pipeline.yml
# Переменные прямого конвейера:
# - VAR передается потомку
# - MYVAR передается потомку
ребенок2:
  курок:
    включают: .child-pipeline.yml
    вперед:
      pipe_variables: правда
# Не пересылать переменные YAML:
# - VAR не передается потомку
# - MYVAR не передается потомку
ребенок3:
  курок:
    включают: . child-pipeline.yml
    вперед:
      yaml_variables: ложь
 
 переменных  Переменные CI/CD — это настраиваемые значения, которые передаются заданиям.
Используйте переменные   для создания пользовательских переменных.
 Переменные всегда доступны в командах  script  ,  before_script  и  after_script  .
Вы также можете использовать переменные в качестве входных данных в некоторых ключевых словах работы.
  Тип ключевого слова  : Глобальное и рабочее ключевое слово. Вы можете использовать его на глобальном уровне,
а также на уровне работы.
 Если вы определяете  переменных  на глобальном уровне, каждая переменная копируется в
каждой конфигурации задания при создании конвейера. Если работа уже имеет это
определена переменная, переменная уровня задания имеет приоритет.
  Возможные входные данные  : Пары имени и значения переменной:
 Имя может использовать только цифры, буквы и знаки подчеркивания (  _  ). В некоторых оболочках
первый символ должен быть буквой.
 Значение должно быть строкой.
 Поддерживаются переменные CI/CD.
  Примеры переменных    :
 переменных:
  DEPLOY_SITE: "https://example.com/"
развертывание_работа:
  этап: развертывание
  сценарий:
    --deploy-script --url $DEPLOY_SITE --path "/"
  среда: производство
deploy_review_job:
  этап: развертывание
  переменные:
    REVIEW_PATH: "/обзор"
  сценарий:
    --deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  среда: производство
 
  Дополнительная информация  :
 Все переменные, определенные в YAML, также устанавливаются для любых связанных сервисных контейнеров Docker.
 Переменные, определенные в YAML, предназначены для неконфиденциальной конфигурации проекта. Хранить конфиденциальную информацию
в защищенных переменных или секретах CI/CD.
 Ручные переменные конвейера
и запланированные переменные конвейера
по умолчанию не передаются нижестоящим конвейерам. Использовать триггер: вперед
для пересылки этих переменных в нижестоящие конвейеры.
  Похожие темы  :
 Вы можете использовать привязки YAML для переменных.
 Предопределенные переменные — это переменные, которые бегун
автоматически создает и делает доступными в задании.
 Вы можете настроить поведение бегуна с помощью переменных.
 переменные:описание  Представлено в GitLab 13.7.
 Используйте ключевое слово описания   для определения предварительно заполненной переменной конвейерного уровня (глобальной).
при запуске конвейера вручную.
 Должен использоваться со значением   для значения переменной.
  Тип ключевого слова  : Глобальное ключевое слово. Вы не можете установить переменные уровня задания для предварительного заполнения при запуске конвейера вручную.
  Возможные входы  :
 Строка.
  Пример  переменных: описание   :
 переменных:
  РАЗВЕРТЫВАНИЕ_СРЕДЫ:
    значение: "постановка"
    description: "Цель развертывания. При необходимости измените эту переменную на "canary" или "production".
 
 когда  Используйте , когда , чтобы настроить условия запуска заданий. Если не определено в задании,
значение по умолчанию , когда: on_success  .
  Тип ключевого слова  : Ключевое слово работы. Вы можете использовать его как часть работы.  когда: всегда  и  когда: никогда  также можно использовать в рабочем процессе : правила  .
  Возможные входы  :
  on_success  (по умолчанию): выполнение задания только в том случае, если все задания на более ранних этапах завершатся успешно.
или есть  allow_failure: правда  .
  manual  : Запуск задания только при ручном запуске.
  всегда  : выполнение задания независимо от состояния заданий на более ранних этапах. Также может использоваться в рабочем процессе : правила  .
  on_failure  : Запускать задание только в случае сбоя хотя бы одного задания на более раннем этапе.
  задержано  : Задержка выполнения задания
на указанную продолжительность.
  никогда  : Не запускать задание. Можно использовать только в  раздел правил  или рабочий процесс : правила  .
  Пример , когда   :
 ступени:
  - строить
  - cleanup_build
  - тест
  - развертывать
  - уборка
build_job:
  этап: сборка
  сценарий:
    - сделать сборку
cleanup_build_job:
  этап: cleanup_build
  сценарий:
    - сборка очистки при сбое
  когда: on_failure
test_job:
  этап: тест
  сценарий:
    - сделать тест
развертывание_работа:
  этап: развертывание
  сценарий:
    - сделать развертывание
  когда: вручную
  среда: производство
задание_очистки:
  этап: уборка
  сценарий:
    - уборка после работы
  когда: всегда
 
 В этом примере сценарий:
 Выполняет  cleanup_build_job  только в случае сбоя  build_job .
 Всегда выполняет  cleanup_job  как последний шаг в конвейере, независимо от
успех или неудача.
 Выполняет  deploy_job , когда вы запускаете его вручную в пользовательском интерфейсе GitLab.
  Дополнительные сведения  :
 В GitLab 13.5 и более поздних версиях вы
можно использовать , когда: вручную  в том же задании, что и  триггер  . В GitLab 13.4 и
ранее их совместное использование вызывало ошибку  jobs:#{job-name}, когда должно быть on_success, on_failure или всегда  .
 Поведение по умолчанию  allow_failure  изменяется на  true  с , когда: вручную  .
Однако, если вы используете , когда: вручную  с  правилами  ,  allow_failure  по умолчанию
к  ложно  .
  Похожие темы  :
 , когда  можно использовать с правилами   для более динамичного управления заданиями.
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя * 
Email * 
Сайт 
  
  
Рубрики
Винторезные станки
Вопросы и ответы
Карусельные станки
Советы мастера
Станок 1М63
Токарные станки
Фрезерные станки
Разное
2019 © Все права защищены. Карта сайта

Маркировка	Угол наклона кровли	Максимальный шаг обрешетки	Особенности изделия
С-8	от 15 градусов	Сплошная	Толщина 0,55 мм; стеновой профнастил из оцинкованной стали; применяется для облицовки стен, потолочных подвесных конструкций, для крыш мансард и павильонов, для ограждающих конструкций и стеновых перегородок.
С-10	до 15 градусов	Сплошная
С-10	более 15 градусов	30 см
С-20	до 15 градусов	Сплошная	Толщина 0,5-0,7 мм; стеновой профнастил, который также может использоваться в качестве кровельного покрытия; изделия имеют небольшую высоту волны, но при этом отличаются достаточной прочностью и жесткостью.
С-20	более 15 градусов	50 см
С-21	до 15 градусов	30 см
С-21	более 15 градусов	65 см
С-44	до 15 градусов	50 см
С-44	более 15 градусов	100 см
Н-60	от 8 градусов	3 м	Толщина 0,7-0,9 мм; несущий профнастил с высокими прочностными характеристиками; профиль позволяет создавать влагостойкие кровли без дополнительной системы герметизации; гофра снабжена ребрами жесткости; используется для кровель жилых и промышленных объектов, односкатных крыш, обладает отменной устойчивостью к снеговым и ветровым нагрузкам, также применяется для возведения каркасных конструкций, для перекрытий, ограждений или для несъемной опалубки.
Н-75	от 8 градусов	4 м
НС-35	до 15 градусов	50 см	Толщина 0,55 мм; универсальный профнастил из оцинкованной стали, с полимерным декоративным покрытием, широко применяется для обустройства кровельных систем, для монтажа арочных конструкций, отделки фасадов, при возведении временных каркасных построек, обустройстве ограждений, для несъемной опалубки и так далее.

Шаблон	Описание совпадений	Пример совпадений
`'*'`	Подстановочный знак `` / 8s не соответствует ни одному символу, но не соответствует ни одному символу. Символ `` — это специальный символ в YAML. Когда вы начинаете шаблон с `*` , вы должны использовать кавычки.	`README.md` `server.rb`
`'*.jsx?'`	`? Символ` соответствует нулю или одному из предшествующих символов.	`Page.js` `Page. jsx`
`'**'`	. Это поведение по умолчанию, если вы не используете фильтр пути .	`all/the/files.md`
`'*.js'`	9Подстановочный знак 0816 * соответствует любому символу, но не соответствует косой черте ( `/` ). Соответствует всем `файлам .js` в корне репозитория.	`app.js` `index.js`
`'**.js'`	Соответствует всем `файлам .17 в репозитории 90`	`index.js` `js/index.js` `src/js/app.js`
docs*1	Все файлы в корне каталога `docs` в корне репозитория.	`docs/README.md` `docs/file.txt`
`docs/**`	в корневом каталоге репозитория 96 / 90docs1	`docs/README. md` `docs/mona/octocat.txt`
`docs/*/.md`	`docs/README.md` `docs/mona/hello-world.md` `docs/a/markdown/file.md`
`'/docs/'`	Любые файлы в каталоге `docs` в любом месте репозитория.	`docs/hello.md` `dir/docs/my-file.txt` `space/docs/plan/space.doc`
`'**/README.md'`	Файл README.md в любом месте репозитория.	`readme.md` `JS/README.MD`
`'*/SRC/**`	8888888 гг.	`a/src/app.js` `my-src/code/js/app.js`
`'*/-post.md'`	92 Файл с расширением0816 -post. md в любом месте репозитория.	`MY-POST.MD` `PATH/IHOR-POST.MD`
`'*/MIGRATE-. SQL'`	8888888 AILIX с Prefix 588888888 A.ILIX `108108.IIL-8.IIL-8.IIL-8.IIX '*/MIGRATE-. .sql в любом месте репозитория.`	`migrate-10909.sql` `db/migrate-v1.0.sql` `db/sept/migrate-v1.sql`
`*.md` `!README.md`	Использование восклицательного знака ( `!` ) перед шаблоном отменяет его. Если файл соответствует шаблону, а также соответствует отрицательному шаблону, определенному в файле позже, файл не будет включен.	`hello.md` Does not match `README.md` `docs/hello.md`
`.md` `!README. md` `README `	Шаблоны проверяются последовательно. Шаблон, отрицающий предыдущий шаблон, будет повторно включать пути к файлам.	`hello.md` `README.md` `README.doc`

Значение	Описание
`пуск`	Значение по умолчанию. Указывает, что задание запускает среду. Развертывание создается после запуска задания.
`подготовка`	Указывает, что задание только подготавливает среду. Он не запускает развертывания. Узнайте больше о подготовке сред.
`stop`	Указывает, что задание останавливает развертывание. Дополнительные сведения см. в разделе Остановить среду.
`проверка`	Указывает, что задание проверяет только среду. Он не запускает развертывания. Узнайте больше о проверке сред.
`доступ`	Указывает, что задание обращается только к среде. Он не запускает развертывания. Узнайте больше о доступе к средам.

Значение	Описание
`API 9081`
`API` 9159
`API`
`.`
`ветвей`	Когда ссылка Git для конвейера является ветвью.
`chat`	Для конвейеров, созданных с помощью команды GitLab ChatOps.
`внешний`	При использовании CI-сервисов, отличных от GitLab.
`external_pull_requests`	При создании или обновлении внешнего запроса на вытягивание в GitHub (см. Конвейеры для внешних запросов на вытягивание).
`merge_requests`	Для конвейеров, созданных при создании или обновлении запроса на слияние. Включает конвейеры запросов на слияние, конвейеры объединенных результатов и поезда слияния.
`конвейеры`	Для многопроектных конвейеров, созданных с помощью API с `CI_JOB_TOKEN` или ключевым словом `триггера` .
`pushs`	Для конвейеров, запускаемых событием `git push` , в том числе для ветвей и тегов.
`расписания`	Для запланированных трубопроводов.
`теги`	Когда ссылка Git для конвейера является тегом. 9стабильная ветвь.$/ - расписания Дополнительные сведения* : Запланированные конвейеры выполняются в определенных ветвях, поэтому задания, настроенные только с `: ветви` также запускать запланированные конвейеры. Добавить `, кроме: расписания` для предотвращения заданий только с `: ветви` от работы по запланированным конвейерам. Только или `, кроме` , используемые без каких-либо других ключевых слов, эквивалентны только `: ссылки` или `кроме: refs` . Например, следующие две конфигурации заданий имеют одинаковую поведение: задание1: сценарий: эхо Только: - ветви задание2: сценарий: эхо Только: ссылки: - ветви Если задание не использует `только` , `кроме` или `правила` , тогда `только` устанавливается на `ветвей` и `тегов` по умолчанию. Например, `задание1` и `задание2` эквивалентны: задание1: скрипт: эхо "тест" задание2: скрипт: эхо "тест" Только: - ветви - теги Только `: переменные` / `кроме: переменные` Используйте ключевые слова `only:variables` или `exclude:variables` для управления добавлением заданий в конвейер в зависимости от состояния переменных CI/CD. `только: переменные` и `кроме: переменные` активно не разрабатываются. `правил:если` является предпочтительным ключевым словом при использовании ссылок, регулярных выражений или переменных для управления когда добавлять задания в пайплайны. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив выражений переменных CI/CD. Пример только `: переменные` : развертывание: скрипт: деплой промежуточной шапки Только: переменные: - $RELEASE == "постановка" - $ ПОСТАНОВКА Похожие темы : Только `: переменные` и `, кроме: переменных` примеров. Только `: изменения` / `кроме: изменения` Используйте ключевое слово `изменяет` с `только` , чтобы запустить задание, или с `, кроме` , чтобы пропустить задание, когда событие Git push изменяет файл. Использовать `изменений` в конвейерах со следующими ссылками: `ответвлений` `external_pull_requests` `merge_requests` (см. дополнительные сведения об использовании 9Только 0816: изменения с конвейерами мерж-реквестов) Только `: изменения` и `, за исключением: изменения` активно не разрабатываются. `правила: изменения` является предпочтительным ключевым словом при использовании измененных файлов для управления добавлением заданий в конвейеры. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив, включающий любое количество: Пути к файлам. Пути с подстановочными знаками для отдельных каталогов, например `path/to/directory/` , или каталог и все его подкаталоги, например `путь/к/каталогу//` . Пути подстановочных знаков для всех файлы с одинаковым или несколькими расширениями, например `.md` или `путь/к/каталогу/.{rb,py,sh}` . См. документацию Ruby `fnmatch` . список поддерживаемого синтаксиса. Пути с подстановочными знаками к файлам в корневом каталоге или во всех каталогах, заключенные в двойные кавычки. Например `".json"` или `"/.json"` . Пример только `: изменения` : сборка докера: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . Только: ссылки: - ветви изменения: - Докерфайл - докер/скрипты/* - файлы докеров/*/ - more_scripts/. {rb,py,sh} - "/.json" Дополнительные детали : `изменений` преобразуется в `true` , если какой-либо из соответствующих файлов изменен (0816 ИЛИ операция ). Если вы используете ссылки, отличные от `ветвей` , `external_pull_requests` или `merge_requests` , `изменений` не может определить, является ли данный файл новым или старым, и всегда возвращает `true` . Если вы используете только `: измените` с другими ссылками, задания игнорируют изменения и всегда выполняются. Если вы используете `, кроме: изменения` с другими ссылками, задания игнорируют изменения и никогда не запускаются. Похожие темы : Только `: изменяет` и `, кроме: изменяет примеры` . Если вы используете `изменений` с разрешением мерж-реквестов только в случае успеха конвейера, вы также должны использовать только `:merge_requests` . Задания или конвейеры могут запускаться неожиданно только при использовании `: изменения` . Только `: kubernetes` / `кроме: kubernetes` Используйте только `: kubernetes` или `, кроме: kubernetes` для управления добавлением заданий в конвейер. когда служба Kubernetes активна в проекте. Только `: ссылки` и `, кроме: ссылки` активно не разрабатываются. Использовать правила `:если` с предопределенной переменной CI/CD `CI_KUBERNETES_ACTIVE` чтобы контролировать, добавляются ли задания в конвейер, когда служба Kubernetes активна в проекте. Тип ключевого слова : Для конкретного задания. Вы можете использовать его только как часть работы. Возможные входные данные : Стратегия `kubernetes` принимает только ключевое слово `active` . Пример только для `: kubernetes` : развертывание: Только: Кубернетес: активен В этом примере задание `развертывания` запускается только тогда, когда служба Kubernetes активна. в проекте. `страниц` Используйте `страниц` , чтобы определить задание GitLab Pages, которое загружает статический контент в GitLab. Затем контент публикуется как веб-сайт. Тип ключевого слова : Имя задания. Пример `страниц` : страниц: этап: развертывание сценарий: - mkdir .public -cp -r * .public - mv .public общественность артефакты: пути: - общественный правила: - если: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH среда: производство В этом примере все файлы перемещаются из корня проекта в каталог `public/`. Обходной путь `.public` так `cp` также не копирует `public/` в себя в бесконечном цикле. Дополнительные сведения : Необходимо: Помещать любой статический контент в каталог `public/`. Определить артефакты с путем к каталогу `public/`. `параллельно` Используйте `parallel` для параллельного запуска задания несколько раз в одном конвейере. Должно существовать несколько исполнителей или одно средство выполнения должно быть настроено для одновременного запуска нескольких заданий. Параллельные задания именуются последовательно от `job_name 1/N` до `job_name N/N` . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Числовое значение от `2` до `50` . Пример `параллельного` : теста: сценарий: rspec параллельно: 5 В этом примере создается 5 параллельно выполняемых заданий с именем `тест 1/5` – `тест 5/5` . Дополнительные сведения : Каждое параллельное задание имеет `CI_NODE_INDEX` и `CI_NODE_TOTAL` предопределенный набор переменных CI/CD. Похожие темы : Распараллеливайте большие задачи. `параллель:матрица` История версий Представлено в GitLab 13.3. Стиль именования заданий был улучшен в GitLab 13.4. Используйте `parallel:matrix` для запуска задания несколько раз параллельно в одном конвейере, но с разными значениями переменных для каждого экземпляра задания. Должно существовать несколько исполнителей или одно средство выполнения должно быть настроено для одновременного запуска нескольких заданий. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив хэшей переменных: В именах переменных могут использоваться только цифры, буквы и знаки подчеркивания ( `_` ). Значения должны быть либо строкой, либо массивом строк. Количество перестановок не может превышать 50. Пример `parallel:matrix` : deploystacks: этап: развертывание сценарий: - бин/развернуть параллельно: матрица: - ПРОВАЙДЕР: aws КУЧА: - мониторинг - приложение1 - приложение2 - ПРОВАЙДЕР: ovh СТЕК: [мониторинг, резервное копирование, приложение] - ПРОВАЙДЕР: [gcp, vultr] СТЕК: [данные, обработка] среда: $PROVIDER/$STACK В этом примере создается 10 параллельных заданий `deploystacks` , каждое из которых имеет разные значения для `PROVIDER` и `STACK` : deploystacks: [aws, мониторинг] развертывание стеков: [aws, app1] развертывание стеков: [aws, app2] deploystacks: [ovh, мониторинг] deploystacks: [ovh, резервная копия] развертывание стеков: [ovh, приложение] развертывание стеков: [gcp, данные] deploystacks: [gcp, обработка] развертывание стеков: [vultr, данные] deploystacks: [vultr, обработка] Похожие темы : Запустите одномерную матрицу параллельных заданий. Запустите матрицу запущенных параллельных заданий. Выберите разные теги бегуна для каждого параллельного матричного задания. `выпуск` Представлено в GitLab 13.2. Используйте версию для создания версии. Задание выпуска должно иметь доступ к `Release-cli` , который должен быть в `$PATH` . Если вы используете исполнитель Docker, вы можете использовать этот образ из реестра контейнеров GitLab: `register.gitlab.com/gitlab-org/release-cli:latest` Если вы используете исполняющую программу Shell или аналогичную, установить `релиз-кли` на сервер, где прописан раннер. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Подключи выпуска : `tag_name` `tag_message` (необязательно) `имя` (опционально) `описание` `№` (дополнительно) `вех` (опционально) `Release_at` (опционально) `assets:links` (необязательно) Пример ключевого слова выпуска : release_job: этап: релиз образ:Registry. gitlab.com/gitlab-org/release-cli:latest правила: - if: $CI_COMMIT_TAG # Запускать это задание, когда тег создается вручную сценарий: - echo "Выполняется задание выпуска." выпускать: имя_тега: $CI_COMMIT_TAG имя: 'Выпустить $CI_COMMIT_TAG' description: 'Релиз создан с помощью Release-cli.' В этом примере создается релиз: При нажатии тега Git. При добавлении тега Git в пользовательский интерфейс в разделе Репозиторий > Теги . Дополнительная информация : Все задания выпуска, за исключением заданий триггера, должны включать ключевое слово `сценария` . Релиз job может использовать вывод команд сценария. Если вам не нужен скрипт, вы можете использовать заполнитель: скрипт : - эхо "выпустить задание" Существует проблема, связанная с удалением этого требования. Раздел выпуска `выполняется после ключевого слова` сценария `и перед after_script .` `Релиз создается только в случае успешного выполнения основного сценария задания.` `Если выпуск уже существует, он не обновляется, и задание с ключевым словом выпуска завершается сбоем.` `Похожие темы :` `Пример CI/CD ключевого слова выпуска .` `Создавайте несколько выпусков в одном конвейере.` `Используйте пользовательский центр сертификации SSL CA.` `Выпуск` : имя_тега Обязательно. Тег Git для релиза. Если тег еще не существует в проекте, он создается одновременно с выпуском. Новые теги используют SHA, связанный с конвейером. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Имя тега. Поддерживаются переменные CI/CD. Пример release:tag_name : Для создания релиза при добавлении в проект нового тега: Используйте переменную $CI_COMMIT_TAG CI/CD 7 в качестве тега 1_ . Использовать правила : если только или : теги для настройки задание запускать только для новых тегов. работа: script: echo "Выполняется задание выпуска для нового тега." выпускать: имя_тега: $CI_COMMIT_TAG description: 'Описание релиза' правила: - если: $CI_COMMIT_TAG Чтобы одновременно создать релиз и новый тег, ваш управляет только или если , а не , настройте задание так, чтобы оно выполнялось только для новых тегов. Пример семантической версии: job: script: echo "Запуск задания выпуска и создание нового тега." выпускать: tag_name: ${MAJOR}_${MINOR}_${REVISION} description: 'Описание релиза' правила: - если: $CI_PIPELINE_SOURCE == "расписание" Выпуск : tag_message Представлено в GitLab 15.3. Поддерживается Release-Cli v0.12.0 или более поздней версии. Если тег не существует, вновь созданный тег аннотируется сообщением, указанным в tag_message . Если он опущен, создается упрощенный тег. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Текстовая строка. Пример release:tag_message : release_job: этап: релиз выпускать: имя_тега: $CI_COMMIT_TAG description: 'Описание релиза' tag_message: 'Аннотированное сообщение тега' Версия : имя Название выпуска. Если он опущен, он заполняется значением выпуска : tag_name . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Текстовая строка. Пример релиз:имя : релиз_работа: этап: релиз выпускать: имя: 'Выпустить $CI_COMMIT_TAG' Выпуск : описание Подробное описание релиза. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Строка с длинным описанием. Путь к файлу, содержащему описание. Представлено в GitLab 13.7. Расположение файла должно быть относительно каталога проекта ( $CI_PROJECT_DIR ). Если файл является символической ссылкой, он должен быть в $CI_PROJECT_DIR . ./path/to/file и имя файла не могут содержать пробелы. Пример выпуска : описание : задание: выпускать: tag_name: ${MAJOR}_${MINOR}_${REVISION} описание: './path/to/CHANGELOG.md' Выпуск : ссылка ref для выпуска, если выпуск : имя_тега еще не существует. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : SHA фиксации, другое имя тега или имя ветки. Выпуск : вехи Название каждой вехи, с которой связан выпуск. Выпуск :released_at Дата и время готовности релиза. Возможные значения : Дата, заключенная в кавычки и выраженная в формате ISO 8601. Пример выпуска :released_at : Release_at: '2021-03-15T08:00:00Z' Дополнительные сведения : Если не указано, используются текущие дата и время. выпуск:активы:ссылки Представлено в GitLab 13.12. Используйте release:assets:links , чтобы включить ссылки на активы в выпуск. Требуется Release-Cli версии v0.4.0 или выше. Пример выпуска : активы: ссылки : активы: ссылки: - имя: 'актив1' URL-адрес: https://example. com/assets/1. - имя: 'актив2' URL-адрес: «https://example.com/assets/2» путь к файлу: '/pretty/url/1' # необязательно link_type: 'другое' # необязательно группа_ресурсов Представлено в GitLab 12.7. Используйте resource_group для создания группы ресурсов, гарантирует, что задание является взаимоисключающим для разных конвейеров одного и того же проекта. Например, если несколько заданий, принадлежащих к одной группе ресурсов, одновременно поставлены в очередь, запускается только одно из заданий. Другие задания ждут, пока resource_group не освободится. Группы ресурсов ведут себя подобно семафорам в других языках программирования. Для каждой среды можно определить несколько групп ресурсов. Например, при развертывании на физические устройства у вас может быть несколько физических устройств. Каждое устройство может быть развернут, но только одно развертывание может произойти на устройство в любой момент времени. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : `только буквы, цифры, - , _ , /, $ , {, } , ,` , . и пробелы. Он не может начинаться или заканчиваться на `/`. Поддерживаются переменные CI/CD. Пример `resource_group` : развертывание в рабочей среде: сценарий: развернуть группа_ресурсов: производство В этом примере два задания `по развертыванию в рабочей среде` в двух отдельных конвейерах никогда не могут выполняться одновременно. Как результат, вы можете гарантировать, что одновременные развертывания никогда не произойдут в производственной среде. Похожие темы : Контроль параллелизма на уровне конвейера с конвейерами между проектами и родителем-потомком. `повторить попытку` Используйте `повторных попыток` , чтобы настроить количество повторных попыток задания в случае сбоя. Если не определено, по умолчанию `0` и задания не повторяются. При сбое задания оно обрабатывается еще два раза до тех пор, пока оно не завершится успешно или достигает максимального количества повторных попыток. По умолчанию все типы сбоев вызывают повторную попытку задания. Использовать `повтор: когда` чтобы выбрать, при каких ошибках повторить попытку. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы или в `раздел по умолчанию` . Возможные входы : `0` (по умолчанию), `1` или `2` . Пример повторной попытки : теста: сценарий: rspec повторить: 2 `повтор: когда` Используйте повторную попытку `: когда` с повторной попыткой `: макс.` , чтобы повторить задания только для определенных случаев сбоя. `retry:max` — максимальное количество повторных попыток, например `retry` , и может быть `0` , `1` или `2` . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы или в `раздел по умолчанию` . Возможные входы : Один тип отказа или массив из одного или нескольких типов отказа: `всегда` : Повторить попытку при любом сбое (по умолчанию). `unknown_failure` : повторите попытку, если причина сбоя неизвестна. `script_failure` : повторите попытку после сбоя сценария. `api_failure` : повторите попытку при сбое API. `stick_or_timeout_failure` : повторите попытку, если задание зависло или истекло время ожидания. `runner_system_failure` : повторите попытку, если произошел сбой системы бегуна (например, сбой настройки задания). `runner_unsupported` : повторите попытку, если бегун не поддерживается. `stale_schedule` : повторите попытку, если отложенное задание не может быть выполнено. `job_execution_timeout` : повторите попытку, если сценарий превысил максимальное время выполнения, установленное для задания. `archived_failure` : повторите попытку, если задание заархивировано и не может быть запущено. `unmet_prerequisites` : повторите попытку, если заданию не удалось выполнить предварительные задачи. `scheduler_failure` : повторите попытку, если планировщику не удалось назначить задание исполнителю. `data_integrity_failure` : повторите попытку, если обнаружена проблема структурной целостности. Пример повторной попытки `: когда` (тип одиночного сбоя): тест: сценарий: rspec повторить: макс: 2 когда: runner_system_failure В случае сбоя, отличного от сбоя системы бегуна, задание не повторяется. Пример повторной попытки `: когда` (массив типов ошибок): тест: сценарий: rspec повторить: макс: 2 когда: - runner_system_failure - застрял_or_timeout_failure Связанные темы : Можно указать количество повторных попыток для определенных этапов выполнения задания. используя переменные. `правила` Представлено в GitLab 12.3. Используйте правила для включения или исключения заданий в конвейерах. Правила оцениваются при создании конвейера и оцениваются в порядке до первого матча. Когда совпадение найдено, задание либо включается, либо исключается из конвейера. в зависимости от конфигурации. Нельзя использовать переменные dotenv, созданные в сценариях заданий, в правилах, так как правила оцениваются перед выполнением любых заданий. `правила` заменяют только `/кроме` и не могут использоваться вместе на той же работе. Если вы настроите одно задание на использование обоих ключевых слов, GitLab вернет ключ `нельзя использовать с ошибкой правил` . `rules` accepts an array of rules defined with: `if` `changes` `exists` `allow_failure` `variables` `когда` Вы можете комбинировать несколько ключевых слов для сложных правил. Задание добавлено в конвейер: Если `if` , `изменяет` или `существует` соответствует правилу, а также имеет `когда: on_success` (по умолчанию), `когда: задержано` или `когда: всегда` . Если достигнуто правило, равное только `, когда: on_success` , `, когда: задержано` , или `, когда: всегда` . Задание не добавлено в конвейер: Если ни одно правило не соответствует. Если правило соответствует и имеет `когда: никогда` . Вы можете использовать теги `!reference` для повторного использования `правил` конфигурации на разных работах. `правил:если` Используйте правила `: условия if` , чтобы указать, когда добавлять задание в конвейер: Если утверждение `if` истинно, добавьте задание в конвейер. Если утверждение `if` верно, но оно сочетается с `, когда: никогда` , не добавлять задание в конвейер. Если нет `, если утверждения` верны, не добавляйте задание в конвейер. `, если` предложений оцениваются на основе значений предопределенных переменных CI/CD или пользовательские переменные CI/CD. Тип ключевого слова : зависит от задания и конвейера. Вы можете использовать его как часть работы для настройки поведения задания или с помощью 9особенность/ когда: вручную allow_failure: правда – если: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME Дополнительные сведения : Если правило соответствует и не имеет `, когда определено` , правило использует `, когда` определено для задания, которое по умолчанию равно `on_success` , если не определено. В GitLab 14.5 и более ранних версиях вы можете определить `, когда` один раз для правила или один раз на уровне задания, что относится ко всем правилам. нельзя смешивать `, когда` на уровне задания с `, когда` в правилах. В GitLab 14.6 и более поздних версиях вы можете смешивать `, когда` на уровне задания, с `, когда` в правилах. `, когда конфигурация` в правилах имеет приоритет над `, когда` на уровне задания. В отличие от переменных в сценарии разделы, переменные в выражениях правил всегда имеют формат `$VARIABLE` . Можно использовать правила `:если` с `включает` для условного включения других файлов конфигурации. Переменные CI/CD в правой части выражений `=~` и `!~` оцениваются как регулярные выражения. Похожие темы : Общие `если` выражений для `правила` . Избегайте дублирования конвейеров. Используйте правила для запуска конвейеров мерж-реквестов. `правил:изменений` Используйте правила `: изменения` , чтобы указать, когда добавлять задание в конвейер, проверяя наличие изменений к конкретным файлам. предостережение Вы должны использовать правила `: изменения` только с ответвлениями или мерж-реквестами . Вы можете использовать правила `: изменяет` с другими типами конвейеров, но правила `: изменяет` всегда оценивается как true, если нет события Git `push` . Конвейеры тегов, запланированные конвейеры, ручные конвейеры, и так далее , а не имеют связанное с ними событие Git `push` . Правила `: изменение задания` всегда добавляется к этим конвейерам, если нет `, если` ограничивает задание до конвейеры ответвлений или мерж-реквестов. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Массив, включающий любое количество: Пути к файлам. В GitLab 13.6 и более поздних версиях пути к файлам могут включать переменные. Массив пути к файлу также может быть в `правила:изменения:пути` . Подстановочные пути для: Отдельные каталоги, например `путь/к/каталогу/` . Каталог и все его подкаталоги, например `путь/к/каталогу//` . Пути подстановочных знаков для всех файлов с одним или несколькими расширениями, например `.md` или `путь/к/каталогу/.{rb,py,sh}` . См. документацию Ruby `fnmatch` . список поддерживаемого синтаксиса. Пути с подстановочными знаками к файлам в корневом каталоге или во всех каталогах, заключенные в двойные кавычки. Например, `". json"` или `"/.json"` . Пример правил `: изменения` : сборка докера: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . правила: - если: $CI_PIPELINE_SOURCE == "merge_request_event" изменения: - Докерфайл когда: вручную allow_failure: правда Если конвейер является конвейером запросов на слияние, отметьте `Dockerfile` для изменений. Если `Dockerfile` изменился, добавьте задание в конвейер как ручное задание, а конвейер продолжает работать, даже если задание не запущено ( `allow_failure: true` ). Если `Dockerfile` не изменился, не добавляйте задание ни в один конвейер (так же, как `, когда: никогда` ). `rules:changes:paths` совпадает с `rules:changes` без любые подразделы. Дополнительная информация : Правила `: изменяет` работает так же, как и `только: изменяет` и `кроме: изменяет` . Вы можете использовать `, когда: никогда не` для реализации правила, аналогичного `, за исключением:changes` . `изменяет` преобразуется в `true` , если изменяется любой из соответствующих файлов (операция `ИЛИ` ). Похожие темы : Задания или конвейеры могут запускаться неожиданно при использовании `правила: изменения` . `правила:изменения:пути` Представлено в GitLab 15.2. Используйте правила `: изменяет` , чтобы указать, что задание добавляется в конвейер, только если оно указано файлы изменены, и используйте `rules:changes:paths` для указания файлов. `правила:изменения:пути` аналогично использованию `правила:изменения` без любые подразделы. Все дополнительные детали и сопутствующие темы остаются прежними. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив путей к файлам. В GitLab 13.6 и более поздних версиях пути к файлам могут включать переменные. Пример `rules:changes:paths` : docker-build-1: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . правила: - если: $CI_PIPELINE_SOURCE == "merge_request_event" изменения: - Докерфайл докер-сборка-2: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . правила: - если: $CI_PIPELINE_SOURCE == "merge_request_event" изменения: пути: - Докерфайл В этом примере оба задания ведут себя одинаково. `правила:изменения:сравнить_с` История версий Представлен в GitLab 15.3 с флагом `ci_rules_changes_compare` . Включено по умолчанию. Обычно доступно в GitLab 15. 5. Флаг функции `ci_rules_changes_compare` удален. Используйте `rules:changes:compare_to` , чтобы указать, с какой ссылкой сравнивать изменения в файлах перечислено под `правила:изменения:пути` . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть задания, и он должен быть объединен с `rules:changes:paths` . Возможные входы : Имя ветки, например `main` , `branch2` или `refs/heads/branch2` . Имя тега, например `tag1` или `refs/tags/tag1` . SHA фиксации, например `2fg31ga14b` . Пример `rules:changes:compare_to` : docker build: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . правила: - если: $CI_PIPELINE_SOURCE == "merge_request_event" изменения: пути: - Докерфайл compare_to: 'refs/heads/branch2' В этом примере задание `docker build` включается только при изменении файла `Dockerfile` . относительно `refs/heads/branch2` , а источником конвейера является событие запроса на слияние. `правил:существует` Представлено в GitLab 12.4. Используйте `exists` для запуска задания, когда в репозитории существуют определенные файлы. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив путей к файлам. Пути относятся к каталогу проекта ( `$CI_PROJECT_DIR` ) и не может напрямую ссылаться за его пределами. Пути к файлам могут использовать шаблоны глобусов. Пример правил `: существует` : задание: скрипт: docker build -t my-image:$CI_COMMIT_REF_SLUG . правила: - существуют: - Докерфайл `Задание` запускается, если `Dockerfile` существует где-либо в репозитории. Дополнительные сведения : Шаблоны Glob интерпретируются с помощью Ruby `File.fnmatch` с флагами `File::FNM_PATHNAME \| Файл::FNM_DOTMATCH \| Файл::FNM_EXTGLOB` . Из соображений производительности GitLab соответствует максимум 10 000 `существующих` шаблонов или пути к файлам. После 10 000-й проверки правила с шаблонными глобусами всегда совпадают. Другими словами, `существует` всегда сообщает `верно` если более 10000 проверок бегать. Репозитории с менее чем 10 000 файлов могут быть затронуты, если `существует` правила проверены более 10000 раз. `существует` преобразуется в `true` , если любой из перечисленных файлов найден (0816 ИЛИ операция ). `правила:allow_failure` Представлено в GitLab 12.8. Используйте `allow_failure: true` в правилах , чтобы разрешить сбой задания без остановки трубопровода. Вы также можете использовать `allow_failure: true` с ручным заданием. Трубопровод продолжается работает, не дожидаясь результата ручного задания. `allow_failure: ложь` в сочетании с `, когда: вручную` в правилах заставляет конвейер ждать руководства задание для запуска, прежде чем продолжить. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : `истина` или `ложь` . По умолчанию `false` , если не определено. Пример правил `:allow_failure` : задание: script: echo "Привет, Правила!" правила: - если: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH когда: вручную allow_failure: правда Если правило соответствует, то задание выполняется вручную с `allow_failure: true` . Дополнительные сведения : Правила уровня `rules:allow_failure` переопределяют уровень задания `allow_failure` , и применяется только тогда, когда определенное правило запускает задание. `правила:переменные` История версий Представлено в GitLab 13.7. Флаг функции удален в GitLab 13.10. Используйте переменные в правилах для определения переменных для конкретных условий. Тип ключевого слова : Для конкретного задания. Вы можете использовать его только как часть работы. Возможные входы : Хэш переменных в формате `ИМЯ-ПЕРЕМЕННОЙ: значение` . Пример правил `: переменные` : задание: переменные: DEPLOY_VARIABLE: «развертывание по умолчанию» правила: - если: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH переменные: # Переопределить DEPLOY_VARIABLE определено DEPLOY_VARIABLE: "deploy-production" # на уровне задания. - если: $CI_COMMIT_REF_NAME =~ /feature/ переменные: IS_A_FEATURE: "true" # Определить новую переменную. сценарий: - echo "Запустить скрипт с $DEPLOY_VARIABLE в качестве аргумента" - echo "Запустить другой скрипт, если $IS_A_FEATURE существует" `скрипт` Используйте сценарий , чтобы указать команды для выполнения бегуном. Для всех заданий, кроме триггерных заданий, требуется ключевое слово сценария . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив, включающий: Однострочные команды. Длинные команды разбиты на несколько строк. Якоря YAML. Поддерживаются переменные CI/CD. Пример сценария : задание 1: скрипт: "комплект exec rspec" задание2: сценарий: - имя-а - пакет exec rspec Дополнительная информация : Когда вы используете эти специальные символы в `Script` , вы должны использовать отдельные цитаты ( `'`) или двойные цитаты ( `"`). . Вы можете игнорировать ненулевые коды выхода Используйте цветовые коды с `скрипт` для облегчения просмотра журналов заданий. Создание настраиваемых складных разделов для упрощения вывода журнала заданий. `секретов` Представлено в GitLab 13.4. Используйте секреты , чтобы указать секреты CI/CD для: Получить от внешнего поставщика секретов. Сделать доступными в задании переменные CI/CD ( `тип файла` по умолчанию). Это ключевое слово должно использоваться с `секретами: хранилище` . `секретов: хранилище` Представлено в GitLab 13.4 и GitLab Runner 13.4. Используйте `secrets:vault` для указания секретов, предоставляемых хранилищем HashiCorp. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : `engine:name` : Название механизма секретов. `двигатель:путь` : Путь к механизму секретов. `путь` : Путь к секрету. `поле` : Имя поля, в котором хранится пароль. Пример `секретов: хранилище` : Чтобы указать все детали явно и использовать механизм секретов КВ-В2: задание: секреты: DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD vault: # Переводится как секрет: `ops/data/production/db`, поле: `пароль` двигатель: название: кв-в2 путь: опс путь: производство/дб поле: пароль Вы можете сократить этот синтаксис. С коротким синтаксисом `двигатель:имя` и `двигатель:путь` оба по умолчанию `kv-v2` : задание: секреты: DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD vault: production/db/password # Переводит в secret: `kv-v2/data/production/db`, поле: `password` Чтобы указать пользовательский путь механизма секретов в кратком синтаксисе, добавьте суффикс, начинающийся с `@` : задание: секреты: DATABASE_PASSWORD: # Сохраняем путь к секрету в этой переменной CI/CD vault: production/db/password@ops # Переводит в секрет: `ops/data/production/db`, поле: `пароль` `секретов:файл` Представлен в GitLab 14. 1 и GitLab Runner 14.1. Используйте `secrets:file` для настройки сохранения секрета как `файл` или `переменная` тип переменная CI/CD По умолчанию секрет передается заданию как `файл` тип переменной CI/CD. Значение секрет хранится в файле, а переменная содержит путь к файлу. Если ваше программное обеспечение не может использовать переменные типа `файла` CI/CD, установите файл `: false` для хранения секретное значение непосредственно в переменной. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : `true` (по умолчанию) или `false` . Пример `секретов: файл` : задание: секреты: DATABASE_PASSWORD: хранилище: production/db/password@ops файл: ложь Дополнительные сведения : Ключевое слово `файла` является настройкой для переменной CI/CD и должно быть вложено в имя переменной CI/CD, не в разделе хранилища `.` услуги Используйте службы , чтобы указать дополнительный образ Docker для запуска сценариев. услуги изображение связано к изображению, указанному в ключевом слове image . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы или в раздел по умолчанию . Возможные входные данные : имя образа службы, включая путь реестра, если необходимо, в одном из следующих форматов: (То же, что и при использовании с последним тегом ) : @ Переменные CI/CD поддерживаются, но не для псевдонима . Пример служб : по умолчанию: изображение: имя: рубин: 2,6 точка входа: ["/bin/bash"] Сервисы: - имя: my-postgres:11. 7 псевдоним: db-postgres точка входа: ["/usr/local/bin/db-postgres"] команда: ["старт"] до_скрипта: - пакетная установка тест: сценарий: - пакетная спецификация рейка exec В этом примере задание запускает контейнер Ruby. Затем из этого контейнера запускается задание другой контейнер, на котором работает PostgreSQL. Затем задание запускает сценарии в этом контейнере. Похожие темы : Доступные настройки для служб . Определите службы в файле .gitlab-ci.yml . Запускайте задания CI/CD в контейнерах Docker. Используйте Docker для создания образов Docker. служба: pull_policy История версий Представлен в GitLab 15.1 с флагом ci_docker_image_pull_policy . Отключено по умолчанию. Включено на GitLab.com и самостоятельно управляется в GitLab 15. 2. Обычно доступно в GitLab 15.4. Флаг функции ci_docker_image_pull_policy удален. Требуется GitLab Runner 15.1 или новее. Политика извлечения, используемая исполнителем для получения образа Docker. `Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть задания или в разделе` по умолчанию . Возможные входные данные : Одна политика извлечения или несколько политик извлечения в массиве. Может быть `всегда` , `если нет` , или `никогда` . Примеры `service:pull_policy` : job1: script: echo "Единая политика извлечения". Сервисы: - имя: postgres:11.6 pull_policy: если нет задание2: script: echo "Несколько политик извлечения". Сервисы: - имя: postgres:11.6 pull_policy: [всегда, если нет] Дополнительные сведения : Если средство выполнения не поддерживает заданную политику извлечения, задание завершается с ошибкой, подобной следующей: `ОШИБКА: Сбой задания (сбой системы): настроенные политики PullPolicies ([всегда]) не разрешены AllowedPullPolicies ([никогда])` . Похожие темы : Запускайте задания CI/CD в контейнерах Docker. Как работают политики вытягивания бегунов. Использование нескольких политик вытягивания. `этап` Используйте `stage` , чтобы определить, на каком этапе выполняется задание. `стадия` может выполняться параллельно (см. Дополнительные сведения ). Если этап не определен, задание по умолчанию использует этап тестирования . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Массив, включающий любое количество имен этапов. Сценические имена могут быть: Стадии по умолчанию. Определяемые пользователем этапы. Пример столика : столика: - строить - тест - развертывать задание1: этап: сборка сценарий: - echo "Это задание компилирует код. " задание2: этап: тест сценарий: - echo "Это задание проверяет скомпилированный код. Оно запускается после завершения этапа сборки." задание3: сценарий: - echo "Это задание также выполняется на этапе тестирования". задание4: этап: развертывание сценарий: - echo "Это задание развертывает код. Оно запускается после завершения этапа тестирования." среда: производство Дополнительные сведения : Задания могут выполняться параллельно, если они выполняются на разных исполнителях. Если у вас есть только один бегун, задания могут выполняться параллельно, если бегун `одновременная настройка` больше, чем `1` . `этап: .pre` Представлено в GitLab 12.4. Используйте этап `.pre` , чтобы запустить задание в начале конвейера. `.до` всегда первый этап в конвейере. Определяемые пользователем этапы выполняются через `.до` . Вам не нужно определять `.pre` в `этапах` . Если конвейер содержит только задания на этапах `.pre` или `.post` , он не запускается. На другом этапе должна быть хотя бы одна другая работа. Тип ключевого слова : Вы можете использовать его только с ключевым словом задания `stage` . Пример стадии `: .pre` : стадии: - строить - тест задание1: этап: сборка сценарий: - echo "Это задание выполняется на этапе сборки." Первая работа: этап: .pre сценарий: - echo "Это задание выполняется на этапе .pre перед всеми остальными этапами." задание2: этап: тест сценарий: - echo "Это задание выполняется на этапе тестирования." `этап: .post` Представлено в GitLab 12.4. Используйте этап `.post` , чтобы запустить задание в конце конвейера. `.пост` всегда является последней стадией конвейера. Определяемые пользователем этапы выполняются до `.post` . Вам не нужно определять `.post` в `этапах` . Если конвейер содержит только задания на этапах `.pre` или `.post` , он не запускается. На другом этапе должна быть хотя бы одна другая работа. Тип ключевого слова : Вы можете использовать его только с ключевым словом задания `stage` . Пример стадии `: .post` : стадии: - строить - тест задание1: этап: сборка сценарий: - echo "Это задание выполняется на этапе сборки." Последнее место работы: этап: .post сценарий: - echo "Это задание выполняется на этапе .post после всех остальных этапов." задание2: этап: тест сценарий: - echo "Это задание выполняется на этапе тестирования." `теги` История версий Ограничение в 50 тегов на задание включено на GitLab. com в GitLab 14.3. Ограничение в 50 тегов на задание включено для самостоятельного управления в GitLab 14.3. Используйте теги для выбора конкретного бегуна из списка всех бегунов, которые доступны для проекта. При регистрации бегуна можно указать теги бегуна, для пример `ruby` , `postgres` или `development` . Чтобы взяться за дело и запустить его, бегун должен быть присвоен каждому тегу, указанному в задании. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы или в `раздел по умолчанию` . Возможные входные данные : Массив имен тегов. Переменные CI/CD поддерживаются в GitLab 14.1 и выше. Пример тегов : задание: теги: - Рубин - постгрес В этом примере только полозья с и и `рубинами` и `тегов postgres` могут выполнять задание. Дополнительные сведения : В GitLab 14.3 и более поздних версиях количество тегов должно быть меньше `50` . Похожие темы : Используйте теги, чтобы контролировать, какие задания может выполнять бегун. Выберите разные теги бегуна для каждого параллельного матричного задания. `тайм-аут` Представлено в GitLab 12.3. Использовать тайм-аут , чтобы настроить тайм-аут для определенного задания. Если работа длится дольше чем тайм-аут, задание не выполняется. Время ожидания на уровне задания может превышать время ожидания на уровне проекта. но не может быть больше тайм-аута бегуна. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы или в `раздел по умолчанию` . Возможные входные данные : Период времени, записанный на естественном языке. Например, все они эквивалентны: `3600 секунд` `60 минут` `один час` скрипт: build.sh тайм-аут: 3 часа 30 минут тест: сценарий: rspec тайм-аут: 3 часа 30 минут `триггер` Используйте триггер , чтобы объявить задание «триггерным заданием», которое запускает нисходящий трубопровод: Многопроектный пайплайн. Дочерний конвейер. Триггерные задания могут использовать только ограниченный набор ключевых слов конфигурации GitLab CI/CD. Ключевые слова, доступные для использования в триггерных заданиях: `триггер` . `этап` . `разрешить_сбой` . `правила` . `только` и `кроме` . `при` (только со значением `on_success` , `on_failure` или `всегда` ). `расширяет` . `нужен` , но не `нужен: проект` . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Для конвейеров с несколькими проектами — путь к нижестоящему проекту. Поддерживаются переменные CI/CD в GitLab 15.3 и более поздних версиях, но не сохраняемые переменные уровня задания. В качестве альтернативы используйте `trigger:project. Для дочерних конвейеров используйте 9Триггер 0816: включить . Пример триггера : триггер-многопроектный-конвейер: триггер: моя группа/мой проект Дополнительные сведения : Вы не можете использовать API для запуска `, когда:ручной запуск` заданий. В GitLab 13.5 и более поздних версиях вы можно использовать `, когда: вручную` в том же задании, что и `, запускающий` . В GitLab 13.4 и ранее их совместное использование вызывало ошибку `jobs:#{job-name}, когда должно быть on_success, on_failure или всегда` . Ручные переменные конвейера и запланированные переменные конвейера по умолчанию не передаются нижестоящим конвейерам. Использовать триггер: вперед для пересылки этих переменных в нижестоящие конвейеры. Сохраняемые переменные уровня задания недоступны в триггерных заданиях. Похожие темы : Примеры конфигурации многопроектного пайплайна. Чтобы запустить конвейер для определенной ветки, тега или фиксации, вы можете использовать токен триггера. для аутентификации с помощью API триггеров конвейера. Токен триггера отличается от `запускает ключевое слово` . Триггер `: включить` Используйте триггер `: включите` , чтобы объявить, что задание является «триггерным заданием», которое запускает дочерний трубопровод. Используйте `trigger:include:artifact` для запуска динамического дочернего конвейера. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входные данные : Путь к файлу конфигурации дочернего конвейера. Пример триггера `: включить` : триггер-дочерний конвейер: курок: включают: путь/к/child-pipeline.gitlab-ci.yml Похожие темы : Примеры конфигурации дочернего конвейера. Триггер `: проект` Используйте триггер `: проект` , чтобы объявить задание «триггерным заданием», которое запускает многопроектный пайплайн. По умолчанию многопроектный конвейер запускается для ветви по умолчанию. Используйте `триггер:ветвь` чтобы указать другую ветвь. Тип ключевого слова : Ключевое слово работы. Вы можете использовать его только как часть работы. Возможные входы : Путь к нижестоящему проекту. Поддерживаются переменные CI/CD в GitLab 15.3 и более поздних версиях, но не сохраняемые переменные уровня задания. Пример триггера `: проект` : триггер-многопроектный-конвейер: курок: проект: моя группа/мой проект Пример триггера `: проект` для другой ветки : триггер-мультипроект-конвейер: курок: проект: моя группа/мой проект отрасль: разработка Похожие темы : Примеры конфигурации многопроектного пайплайна. Чтобы запустить конвейер для определенной ветки, тега или фиксации, вы также можете использовать токен триггера. для аутентификации с помощью API триггеров конвейера. Токен триггера отличается от `запускает ключевое слово` . `триггер:стратегия` Используйте `триггер: стратегия` , чтобы заставить задание `триггера` ожидать завершения нисходящего конвейера до того, как он будет помечен как , успех . Это поведение отличается от поведения по умолчанию, которое заключается в том, что задание триггера помечается как успех , как только нижестоящий конвейер будет создан. Этот параметр делает выполнение конвейера линейным, а не параллельным. Пример триггера `: стратегия` : trigger_job: курок: включают: путь/к/child-pipeline.yml стратегия: зависеть В этом примере задания из последующих стадий ожидают запуска запущенного конвейера. успешно завершить перед началом. Дополнительная информация : Дополнительные ручные задания в нисходящем конвейере не влияют на состояние нижестоящего конвейера или вышестоящего триггерного задания. Нисходящий конвейер может успешно завершиться без выполнения каких-либо дополнительных ручных заданий. Блокирование ручных заданий в нисходящем конвейере должен выполняться до того, как задание триггера будет помечено как успешное или неудачное. Триггерная работа показывает в ожидании (), если статус нижестоящего конвейера Ожидание ручного действия () из-за ручных заданий. По умолчанию, задания на более поздних этапах не запускаются до тех пор, пока не завершится задание триггера. `триггер:вперед` История версий Представлен в GitLab 14.9 с флагом 9.0816 ci_trigger_forward_variables . Отключено по умолчанию. Включено на GitLab.com и самоуправляемо в GitLab 14.10. Общедоступно в GitLab 15.1. Флаг функции `ci_trigger_forward_variables` удален. Используйте `trigger:forward` , чтобы указать, что пересылать в нижестоящий конвейер. Вы можете контролировать что пересылается в оба родительско-дочерних конвейера и многопроектные пайплайны. Возможные входы : `yaml_variables` : `true` (по умолчанию) или `false` . Когда `истинно` , переменные определены в задании триггера передаются нижестоящим конвейерам. `pipe_variables` : `true` или `false` (по умолчанию). Когда `true` , ручные переменные конвейера и запланированные переменные конвейера передаются в нисходящие трубопроводы. Пример `триггера:вперед` : Запустите этот конвейер вручную с помощью переменная CI/CD `MYVAR = мое значение` : переменные: # переменные по умолчанию для каждого задания ВАР: значение # Поведение по умолчанию: # - VAR передается потомку # - MYVAR не передается потомку ребенок1: курок: включают: .child-pipeline.yml # Переменные прямого конвейера: # - VAR передается потомку # - MYVAR передается потомку ребенок2: курок: включают: .child-pipeline.yml вперед: pipe_variables: правда # Не пересылать переменные YAML: # - VAR не передается потомку # - MYVAR не передается потомку ребенок3: курок: включают: . child-pipeline.yml вперед: yaml_variables: ложь `переменных` Переменные CI/CD — это настраиваемые значения, которые передаются заданиям. Используйте переменные для создания пользовательских переменных. Переменные всегда доступны в командах `script` , `before_script` и `after_script` . Вы также можете использовать переменные в качестве входных данных в некоторых ключевых словах работы. Тип ключевого слова : Глобальное и рабочее ключевое слово. Вы можете использовать его на глобальном уровне, а также на уровне работы. Если вы определяете `переменных` на глобальном уровне, каждая переменная копируется в каждой конфигурации задания при создании конвейера. Если работа уже имеет это определена переменная, переменная уровня задания имеет приоритет. Возможные входные данные : Пары имени и значения переменной: Имя может использовать только цифры, буквы и знаки подчеркивания ( `_` ). В некоторых оболочках первый символ должен быть буквой. Значение должно быть строкой. Поддерживаются переменные CI/CD. Примеры переменных : переменных: DEPLOY_SITE: "https://example.com/" развертывание_работа: этап: развертывание сценарий: --deploy-script --url $DEPLOY_SITE --path "/" среда: производство deploy_review_job: этап: развертывание переменные: REVIEW_PATH: "/обзор" сценарий: --deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH среда: производство Дополнительная информация : Все переменные, определенные в YAML, также устанавливаются для любых связанных сервисных контейнеров Docker. Переменные, определенные в YAML, предназначены для неконфиденциальной конфигурации проекта. Хранить конфиденциальную информацию в защищенных переменных или секретах CI/CD. Ручные переменные конвейера и запланированные переменные конвейера по умолчанию не передаются нижестоящим конвейерам. Использовать триггер: вперед для пересылки этих переменных в нижестоящие конвейеры. Похожие темы : Вы можете использовать привязки YAML для переменных. Предопределенные переменные — это переменные, которые бегун автоматически создает и делает доступными в задании. Вы можете настроить поведение бегуна с помощью переменных. `переменные:описание` Представлено в GitLab 13.7. Используйте ключевое слово описания для определения предварительно заполненной переменной конвейерного уровня (глобальной). при запуске конвейера вручную. Должен использоваться со значением для значения переменной. Тип ключевого слова : Глобальное ключевое слово. Вы не можете установить переменные уровня задания для предварительного заполнения при запуске конвейера вручную. Возможные входы : Строка. Пример `переменных: описание` : переменных: РАЗВЕРТЫВАНИЕ_СРЕДЫ: значение: "постановка" description: "Цель развертывания. При необходимости измените эту переменную на "canary" или "production". `когда` Используйте `, когда` , чтобы настроить условия запуска заданий. Если не определено в задании, значение по умолчанию `, когда: on_success` . Тип ключевого слова : Ключевое слово работы. Вы можете использовать его как часть работы. `когда: всегда` и `когда: никогда` также можно использовать в рабочем процессе `: правила` . Возможные входы : `on_success` (по умолчанию): выполнение задания только в том случае, если все задания на более ранних этапах завершатся успешно. или есть `allow_failure: правда` . `manual` : Запуск задания только при ручном запуске. `всегда` : выполнение задания независимо от состояния заданий на более ранних этапах. Также может использоваться в рабочем процессе `: правила` . `on_failure` : Запускать задание только в случае сбоя хотя бы одного задания на более раннем этапе. `задержано` : Задержка выполнения задания на указанную продолжительность. `никогда` : Не запускать задание. Можно использовать только в `раздел правил` или рабочий процесс `: правила` . Пример `, когда` : ступени: - строить - cleanup_build - тест - развертывать - уборка build_job: этап: сборка сценарий: - сделать сборку cleanup_build_job: этап: cleanup_build сценарий: - сборка очистки при сбое когда: on_failure test_job: этап: тест сценарий: - сделать тест развертывание_работа: этап: развертывание сценарий: - сделать развертывание когда: вручную среда: производство задание_очистки: этап: уборка сценарий: - уборка после работы когда: всегда В этом примере сценарий: Выполняет `cleanup_build_job` только в случае сбоя `build_job` . Всегда выполняет `cleanup_job` как последний шаг в конвейере, независимо от успех или неудача. Выполняет `deploy_job` , когда вы запускаете его вручную в пользовательском интерфейсе GitLab. Дополнительные сведения : В GitLab 13.5 и более поздних версиях вы можно использовать `, когда: вручную` в том же задании, что и `триггер` . В GitLab 13.4 и ранее их совместное использование вызывало ошибку `jobs:#{job-name}, когда должно быть on_success, on_failure или всегда` . Поведение по умолчанию `allow_failure` изменяется на `true` с `, когда: вручную` . Однако, если вы используете `, когда: вручную` с `правилами` , `allow_failure` по умолчанию к `ложно` . Похожие темы : `, когда` можно использовать с правилами для более динамичного управления заданиями. Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт Рубрики Винторезные станки Вопросы и ответы Карусельные станки Советы мастера Станок 1М63 Токарные станки Фрезерные станки Разное 2019 © Все права защищены. Карта сайта

Ключевое слово	Описание
`default`	Пользовательские значения по умолчанию для заданий.
`include`	Импорт конфигурации из других файлов YAML.
`ступени`	Названия и порядок этапов конвейера.
`переменные`	Определите переменные CI/CD для всех заданий в конвейере.
`рабочий процесс`	Управление типами конвейера.

Ключевое слово	Описание
`after_script`	Переопределяют набор команд, выполняемых после задания.
`allow_failure`	Разрешить сбой задания. Неудачное задание не приводит к сбою конвейера.
`артефакты`	Список файлов и каталогов, которые необходимо прикрепить к заданию в случае успеха.
`before_script`	Переопределить набор команд, которые выполняются перед заданием.
`кэш`	Список файлов, которые следует кэшировать между последующими запусками.
`покрытие`	Параметры покрытия кода для данного задания.
`dast_configuration`	Использовать конфигурацию из профилей DAST на уровне задания.
`зависимости`	Ограничьте передачу артефактов конкретному заданию, предоставив список заданий, из которых нужно получить артефакты.
`среда`	Имя среды, в которой развертывается задание.
`кроме`	Управление, когда задания не создаются.
`extends`	Записи конфигурации, от которых наследуется это задание.
`образ`	Используйте образы Docker.
`наследовать`	Выберите, какие глобальные значения по умолчанию наследуют все задания.
`прерываемый`	Определяет, может ли задание быть отменено, если оно становится избыточным при новом запуске.
`потребности`	Выполнение работ до стадии заказа.
`только`	Управление созданием заданий.
`страниц`	Загрузите результат задания для использования с GitLab Pages.
`параллельно`	Сколько экземпляров задания должно выполняться параллельно.
`выпуск`	Указывает бегуну создать объект выпуска.
`группа_ресурсов`	Ограничение одновременности заданий.
`повтор`	Когда и сколько раз задание может быть автоматически повторено в случае сбоя.
`правила`	Список условий для оценки и определения выбранных атрибутов задания, а также того, создано оно или нет.
`сценарий`	Сценарий оболочки, который выполняется бегуном.
`секреты`	Секреты CI/CD необходимы для работы.
`services`	Используйте образы служб Docker.
`этап`	Определяет этап задания.
`теги`	Список тегов, которые используются для выбора бегуна.
`время ожидания`	Определите пользовательское время ожидания на уровне задания, которое имеет приоритет над настройкой всего проекта.
`триггер`	Определяет триггер нисходящего конвейера.
`переменные`	Определите переменные задания на уровне задания.
`когда`	Когда запускать задание.