Где должны храниться данные коммитов / сборок? - PullRequest
Новая
       67

Где должны храниться данные коммитов / сборок?

0 голосов
/ 12 февраля 2020

Вопрос: Каков наилучший способ сохранить идентификатор фиксации Git для тестового прогона?

Подробности:

Я интегрирую GitLab -> SoapUI -> Kiwi с помощью API JSON -RP C. Я создаю новые тестовые прогоны для каждого регрессионного прогона, запускаемого коммитом Git. Я хочу сохранять идентификатор фиксации Git в каждом тестовом прогоне.

Похоже, что версия продукта подойдет для этой цели. Однако, когда я создаю новую версию (или повторно использую существующую) и затем включаю product_version_id в вызов TestRun.create, версия не ассоциируется с тестовым прогоном.

Вот некоторые из них code: 

testRunCreateString = {
    'build': buildID,
    'manager': 2,
    'plan': 22,
    'summary': 'Running Regression Suite',
    'product_version_id': version,
    }

response = client.send(Request("TestRun.create", values=testRunCreateString))

Я вижу в коде для класса TestRun, что product_version может вскоре устареть для TestRun: 

class TestRun(TCMSActionModel):
    history = KiwiHistoricalRecords()

    # todo: this field should be removed in favor of plan.product_version
    # no longer shown in edit forms

Так что, если product_version будет / будет сохранен в плане тестирования основа, и я не хочу создавать новые планы тестирования для каждого прогона регрессии, каков наилучший способ сохранения Git данных идентификатора фиксации для каждого прогона?

Обновление:

Понятно что в testruns_testrun или testrun_testexecution нет полей product_ *, только в testplans_testplan. Мне не нужен совершенно новый план для каждого регрессионного теста - для каждого проекта могут быть сотни, и в этом количестве они будут бессмысленными.

Я мог бы добавить ссылку на коммит Gitlab (CI_REPOSITORY_URL / commit / CI_COMMIT_SHA) к выполнению теста, когда я добавляю результаты.

Есть идеи получше?

1 Ответ

0 голосов
/ 13 февраля 2020

Чтобы ответить на ваш первоначальный вопрос:

все наши плагины инфраструктуры тестирования предполагают, что коммит sha представляет собой номер сборки b / c каждый коммит - это, по сути, немного другой вариант продукта. Может быть, идет к следующей версии. В этих же плагинах имя ветви и / или номер запроса на получение ответа считается версией b / c, перед тем как все сделать правильно, вы можете сделать несколько перестроек / толчков. Вы можете искать TP / TR на https://tcms.kiwitcms.org (поиск опубликован c), чтобы увидеть это в действии.

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

Я вижу, что нет полей product_ * в testruns_testrun или testrun_testexecution, только в testplans_testplan. Мне не нужен совершенно новый план для каждого регрессионного теста - их может быть несколько для каждого проекта, и они будут бессмысленными в этом количестве.

Right, TestExecution и TestRun объекты знают только о сборках см. рисунок здесь: https://kiwitcms.readthedocs.io/en/latest/guide/introduction.html#data -организация-в-киви-tcms , а также здесь https://kiwitcms.readthedocs.io/en/latest/db.html

Таким образом, вы можете иметь 1 TP для каждого продукта и затем создайте новые TR для каждого коммита / сборки / метки времени. Вы можете установить Version на 1.0 (master или что-то еще), а затем использовать поле Build для представления информации о коммите. Вы также можете добавить это в TR.summary в качестве префикса или добавить его в заметки, комментарии и т. Д. c.

...