Skip to main content

Устранение неполадок с обязательными проверками состояния

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

Кто эту функцию можно использовать?

Защищенные ветви доступны в общедоступных репозиториях с GitHub Free и GitHub Free для организаций, а также в общедоступных и частных репозиториях с GitHub Pro, GitHub Team, GitHub Enterprise Cloudи GitHub Enterprise Server. Дополнительные сведения см. в разделе "Планы GitHub".

Если у вас есть проверка и состояние с одинаковыми именами и вы выбираете это имя в качестве обязательной проверки состояния, обязательными будут и проверка, и состояние. Дополнительные сведения см. в разделе Конечные точки REST API для проверка.

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

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

Примечание. Синхронизировать личную ветвь с базовой можно также путем перемещения изменений из одной ветви в другую в GIT. Дополнительные сведения см. в разделе О перемещении изменений между ветвями в Git.

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

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing

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

Необходимые проверка должны быть успешными в соответствии с последней фиксацией SHA

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

Конфликты между головной фиксацией и тестовой фиксацией слияния

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

Если между фиксацией слияния теста и фиксацией головы возникает конфликт, проверка для фиксации тестового слияния отображаются в поле запроса на вытягивание проверки состояния. Это указано в поле состояния запроса на вытягивание строкой, начиная Showing checks for the merge commitс. Дополнительные сведения о фиксациях тестового слияния см. в разделе "Конечные точки REST API для запросов на вытягивание".

Обработка пропущенных, но обязательных проверок

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

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging)".

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

Пример

В следующем примере показан рабочий процесс, требующий состояния завершения "Успешно" для задания build, но рабочий процесс будет пропущен, если запрос на вытягивание не изменяет файлы в каталоге scripts.

name: ci
on:
  pull_request:
    paths:
      - 'scripts/**'
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

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

Не следует использовать фильтрацию пути или ветви, чтобы пропустить выполнение рабочего процесса, если рабочий процесс необходим для передачи перед слиянием. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging)".

Обязательные проверки состояния из непредвиденных источников

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

Required status check "build" was not set by the expected GitHub App.