Трубопровод Дженкинса: возвращаемое значение шага сборки

Question

В этом конвейере интеграции в Дженкинсе я запускаю разные сборки параллельно, используя шаг сборки , как показано ниже:

stage('trigger all builds')
{
  parallel
  {
    stage('componentA')
    {
      steps
      {
        script 
        {
          def myjob=build job: 'componentA', propagate: true, wait: true
        }
      }
    }
    stage('componentB')
    {
      steps 
      {
        script
        {
          def myjob=build job: 'componentB', propagate: true, wait: true
        }
      }
    }
  }
}

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

Я обнаружил в примерах, что возвращаемый объект имеет геттеры типа getProjectName() или getNumber(), которые я могу использовать для этого.

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

Answer 1

Документация шага генерируется на основе некоторых файлов, связанных с плагином, чего иногда недостаточно. Одним простым способом было бы просто распечатать class объекта результата, вызвав getClass:

def myjob=build job: 'componentB', propagate: true, wait: true
echo "${myjob.getClass()}"

Этот вывод скажет вам, что результатом (в данном случае) является org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper, в котором опубликован Javadoc .

В других случаях мне обычно приходится погружаться в исходный код Jenkins. Вот моя общая стратегия:

• Выясните, какой плагин используется для шага, с помощью документации по шагу, jenkins.io, ссылка на шаг , или просто поиска в Интернете
• С сайта плагина перейдите в репозиторий исходного кода

• Найдите строковый литерал имени шага и найдите тип шага, который его возвращает. В этом случае он выглядит как класс BuildTriggerStep, который extends AbstractStepImpl

  @Override
  public String getFunctionName() {
      return "build";
  }
  

• Посмотрите на вложенное DescriptorImpl, чтобы увидеть, какой класс выполнения возвращается

  public DescriptorImpl() {
      super(BuildTriggerStepExecution.class);
  }
  

• Перейдите к BuildTriggerStepExecution и посмотрите на тело выполнения в методе start()

• Чтение по шагу рабочего процесса README показывает, что что-то должно вызвать context.onSuccess(value), чтобы вернуть результат. В этом файле есть только одно место, но это только случай «без ожидания», который всегда возвращается немедленно и равен null ( source ).

  if (step.getWait()) {
      return false;
  } else {
      getContext().onSuccess(null);
      return true;
  }
  

• Хорошо, значит, он не завершается при выполнении шага, поэтому он должен быть где-то еще. Мы также можем найти в хранилище onSuccess и посмотреть, что еще может вызвать его из этого плагина. Мы находим, что реализация RunListener обрабатывает асинхронную установку результата для выполнения шага, если он был настроен таким образом:

  for (BuildTriggerAction.Trigger trigger : BuildTriggerAction.triggersFor(run)) {
      LOGGER.log(Level.FINE, "completing {0} for {1}", new Object[] {run, trigger.context});
      if (!trigger.propagate || run.getResult() == Result.SUCCESS) {
          if (trigger.interruption == null) {
              trigger.context.onSuccess(new RunWrapper(run, false));
          } else {
              trigger.context.onFailure(trigger.interruption);
          }
      } else {
          trigger.context.onFailure(new AbortException(run.getFullDisplayName() + " completed with status " + run.getResult() + " (propagate: false to ignore)"));
      }
  }
  run.getActions().removeAll(run.getActions(BuildTriggerAction.class));
  

• trigger.context.onSuccess(new RunWrapper(run, false)); - это результат RunWrapper, полученный из