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

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

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

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

В этой статье

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

Note

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

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

Note

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

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

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

Note

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

Требуется проверка, необходимая для успешного выполнения последней фиксации SHA

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

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

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

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

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

Warning

Если рабочий процесс пропускается из-за [фильтрации путей, фильтрации ветвей](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) или сообщения фиксации, то проверки, связанные с этим рабочим процессом, останутся в состоянии "Ожидание". Запрос на включение внесенных изменений, требующий успешной проверки, будет заблокирован при слиянии.

Не следует использовать фильтрацию путей или ветвей, чтобы пропустить выполнение рабочего процесса, если рабочий процесс является обязательным. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Пропуск запусков рабочих процессов](/actions/using-workflows/required-workflows)".

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

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

Пример

В следующем примере показан рабочий процесс, требующий состояния завершения "Успешно" для задания 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" и "Пропуск запусков рабочих процессов](/actions/using-workflows/required-workflows)".

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

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

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