Пользовательский плагин TeamCity с функцией сборки, которая выполняет длительный процесс - PullRequest
0 голосов
/ 07 ноября 2018

Я разрабатываю собственный плагин TeamCity, который интегрируется с платформой развертывания предприятия. Он должен развернуть двоичные файлы в конце сборки на некоторой платформе развертывания, выполнив команду командной строки. В настоящее время существует класс, который расширяет класс BuildFeature на стороне сервера, чтобы настроить детали развертываемых артефактов. На стороне агента есть класс, который расширяет класс AgentLifeCycleAdapter, который переопределяет метод beforeBuildFinish () и выполняет длительный процесс командной строки. Я использую класс SimpleCommandLineProcessRunner для выполнения процесса внешней командной строки:

final ExecResult result = SimpleCommandLineProcessRunner.runCommand(commandLine,
        null,
        new SimpleCommandLineProcessRunner.RunCommandEventsAdapter());

Процесс останавливается через две минуты, что выглядит как тайм-аут:

[18:13:50] Запуск от имени atom_builder [18:13:50] Выполнение C: \ TeamCity \ buildAgent \ work \ db4107aa7e390a67 \ adeploy \ adeploy.exe artifactVersion push C: \ TeamCity \ buildAgent \ работы \ db4107aa7e390a67 \ агент \ атом-агент-артефакт-version.xml [ 18: 13: 50 ] Запуск в C: \ TeamCity \ buildAgent \ work \ db4107aa7e390a67 \ agent [ 18: 15: 22 * ​​1012 *] 2018-11-07 18:13:51 [Информация] ["ArtifactPushService: PushArtifactAsync"] Вызов метода с параметрами "adeploy.exe" [18:15:22] Код выхода: -1

Как правильно выполнять длительные процессы как часть сборки, если в конфигурации сборки есть пользовательская функция сборки?

1 Ответ

0 голосов
/ 08 ноября 2018

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

Поскольку речь идет о пользовательском плагине, он полностью находится в коде агентской части плагина, который выполняет внешний процесс. Как указано в вопросе, внешний процесс выполняется с использованием класса SimpleCommandLineProcessRunner и передает экземпляр класса RunCommandEventsAdapter. Последний возвращает нуль в методе getOutputIdleSecondsTimeout (). Это означает, что SimpleCommandLineProcessRunner будет использовать тайм-аут по умолчанию, равный 90 секундам, если он не определен в параметре teamcity.execution.timeout.

Таким образом, решение состоит в том, чтобы определить класс LongRunningProcessRunCallback, который реализует интерфейс ProcessRunCallback. Обратите внимание, что getOutputIdleSecondsTimeout () возвращает довольно длительное время ожидания.

public class LongRunningProcessRunCallback implements SimpleCommandLineProcessRunner.ProcessRunCallback {

    private static final int DEFAULT_TIMEOUT_SECONDS = 60 * 60 * 24;

    @Nullable
    @Override
    public Integer getMaxAcceptedOutputSize() {
        return null;
    }

    @Override
    public void onProcessStarted(@NotNull Process process) {

    }

    @Override
    public void onProcessFinished(@NotNull Process process) {

    }

    @Nullable
    @Override
    public Integer getOutputIdleSecondsTimeout() {
        return TeamCityProperties.getInteger("teamcity.execution.timeout", DEFAULT_TIMEOUT_SECONDS);
    }
}

А затем передать его SimpleCommandLieProcessRunner:

final ExecResult result = SimpleCommandLineProcessRunner.runCommand(commandLine,
                null,
                new LongRunningProcessRunCallback());
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...