Как можно избежать pu sh в Github, когда тесты рабочего процесса не проходят? - PullRequest
Новая
       14

Как можно избежать pu sh в Github, когда тесты рабочего процесса не проходят?

0 голосов
/ 27 апреля 2020

Я создаю рабочий процесс для проверки моего Python приложения перед фиксацией. Проблема заключается в том, что если тесты не пройдены, фиксация все равно будет передана. Как я мог бы добавить условие, чтобы избежать pu sh, если тест не пройден?

Структура файла рабочего процесса .yml здесь ниже.

`name: Python application on: pu sh: филиалы: [мастер] pull_request: филиалы: [мастер]

задания: сборка: 

runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2
- name: Set up Python 3.8
  uses: actions/setup-python@v1
  with:
    python-version: 3.8
- name: Install dependencies
  run: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt
- name: Lint with flake8
  run: |
    pip install flake8
    # stop the build if there are Python syntax errors or undefined names
    flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
    # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
    flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
- name: Test with pytest
  run: |
    pip install pytest
    pytest`

Скриншот неудачного теста

1 Ответ

0 голосов
/ 28 апреля 2020

Вы не можете фактически предотвратить pu sh с помощью системы CI по нескольким причинам.

Во-первых, вашей системе CI необходим доступ к данным для pu sh, что означает, что он должен где-то жить в хранилище, чтобы его можно было получить. Во-вторых, системам CI может потребоваться много времени для запуска, и никто не хочет бездельничать и ждать, пока их pu sh либо преуспеет, либо выйдет из строя, пока их система CI работает. Что, если вы подтолкнули прямо перед концом рабочего дня?

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

on: push
...