11:49 <Foxboron> Say you have a build trigger that triggers multiple builds. Is there any easy way for me to generate all triggers in one go and go "please wait for the previous trigger and depend on the result of the trigger"? or should I nest the triggers?

11:50 <Foxboron> I think the recommendation I saw was nesting the triggers, but I was a bit curious if it would be possible to have some dependency resolution on the triggers

11:50 <Foxboron> A "dependant trigger" would be cool

11:51 <cmouse> you can trigger builds as steps

11:52 <cmouse> https://docs.buildbot.net/latest/manual/configuration/steps/trigger.html#step-trigger

11:52 <Foxboron> Yes, but I can't have that trigger be dependant on and more previously triggered steps

11:52 <cmouse> you can

11:52 <Foxboron> how can i tell steps.Trigger to depend on another steps.Trigger?

11:53 <cmouse> depends what sort of dependency there is

11:53 <Foxboron> What options do I have?

11:53 <cmouse> all steps, including the Trigger step, have https://docs.buildbot.net/latest/manual/configuration/steps/common.html#buildstep-common-parameters

11:54 <cmouse> haltOnFailure, alwaysRun and doStepIf are probably of your interest here

11:54 <Foxboron> Mm, so you'd have a doStepIf that would have a defered callback that would only resolve after the trigger has been completed?

11:55 <Foxboron> or something like that?

11:55 <cmouse> before build step

11:55 <cmouse> doStepIf is evaluated before entering the step

11:55 <Foxboron> Yes, then I don't see how that helps

11:55 <cmouse> well you are being very mysterious about your usecase.

11:56 <Foxboron> I'm not trying to be mysterious :p I'm just not great at explaining this

11:56 <cmouse> well, you could start by explaining what exactly you are after

11:56 <cmouse> in specific terms

11:56 <Foxboron> I'm writing a buildbot for building for Arch Linux. I have the basics done but one usecase is having a dependant rebuild of packages where the package artifact of the previous build is included in the next build.

11:56 <Foxboron> I.e for bootstrapping toolchains or testing new so-name bumps

11:57 <Foxboron> a buildbot for building packages for Arch Linux*

11:58 <cmouse> so it would just have to start after the previous step?

11:58 <Foxboron> The previous scheduled build. Not step

11:59 <Foxboron> One package build is one Build Factory

12:00 <cmouse> so .. you could trigger the next schdule with Trigger?

12:00 <cmouse> https://docs.buildbot.net/latest/manual/configuration/schedulers.html#dependent-scheduler there is also this

12:00 <Foxboron> Yes, that is what I meant with having "nesting the triggers"

12:02 <Foxboron> Nesting the triggers feel less elegant, but I think it would make more sense as I could append the built artifacts to the properties

12:02 <Foxboron> https://gitlab.archlinux.org/foxboron/archlinux-buildbot/-/tree/master/master fwiw, but there is no documentation :p

21:23 <Zorry> have some problems with docker latent worke that get disconneted when it still running the build https://dpaste.com/H6VJ2F57V