Romario21, я имею в виду, где вы объявляете, что такое context? Какой тип у этой переменной?
Я вижу запись context = this;
Но не вижу объявления context;
Если оно где-то есть - хорошо
Просто отметил, что код в таком виде, в каком вы его представили, не скомпилится
Stanislav Pugachev, но мы не создаем больше джоб
есть джоба на сборку. есть на прогон тестов, есть на управление конфигами и на деплой
Лежат там себе и вызываются. Не куча - 5 штук.
Наверн, multipipeline проще. Чем - я не оч понял Проблем не испытываем
web_dev, да никак)
1. Выгружается с репозитория jenkinsfile
2. Скрипт анализируется и выполняется
3. Все. Дальше сам файл уже не нужен
4. У меня в эту же директорию выгружается в проект и собирается. Все норм)
web_dev, в отдельном
Наверное, если у вас код в ветках продукта сильно отличается и какую-нибудь ветку А нужно собирать не так, как ветку В, то вам стоит держать в каждой ветке поп jenkins-файлу, чтобы там определить индивидуальную сборку для ветки
У нас все ветки собираются одинаково, гоняются одни и те же тесты. Разница только в том, что, если ветка release - после сборки готовимся к деплою
Но эта логика прописана прям в скрипте: отдельный jenkins-файл для ветки - эт уже перебор
так, ну давайте начнем с самого простого:
а нет такого, что вы запустили тест в GUI, а потом Non-GUI и пишете в тот же лог-файл?
Это объяснит, откуда у вас 2 теста
Egorian, в ответе написано -
protected bool canWalk {get;set;}
Вы так будете очень долго делать свой проект, если на базовых вещах языка буксуете. Уделите время - прочтите https://metanit.com/sharp/tutorial/
vad1mi, итог такой. Если хоститесь на IIS, смело берите ASP.NET и пишите свое апи
Если планируется кроссплатформенность - ASP.NET Core
В обоих случаях, тип проекта - WebAPI
Пишете апи и клиент к нему на (React/Angular/Vue/Backbone/и т.д.)