I think it is fine to expect some infrequent scanning - it probably needs to be the default though as otherwise people wire up a webhook - and end up never deleting branches.
On Wednesday, June 21, 2017 at 6:49:02 PM UTC+10, Stephen Connolly wrote: > > On 21 June 2017 at 01:16, Michael Neale <[email protected] > <javascript:>> wrote: > >> Mark do you have a scan interval set? >> >> Should the github events include removing of branch projects? as that >> doesn't seem to be happening lately (since a few months). >> > > So the multibranch API does not allow us to know if an event about a > branch being removed from one source means that the job is now orphaned. > > You can have multiple sources, in which case removing the branch in one > source may mean that a lower-priority source now claims ownership of the > branch. > > If we have one and only one source (ACK that this is likely the majority > case) then and only then can we know that an event removing a branch has > orphaned an item... but even that doesn't get us far. > > The orphaned item strategy may say keep the last 10... so now, in an event > we actually have to go and collect all the currently orphaned items, sort > them by last active and then trim the oldest... which makes the event code > cease being single responsibility as the branch the event was for may or > may not correspond to the job being removed... perhaps the solution is that > we limit the event to deleting its own job if it is not in the last 10... > > Oh but it gets worse... the strategy mat say keep for at least 7 days... > so now, in an event, we should not delete the orphaned item, rather we > should queue up a task to run in 7 days time that would then delete the > item (not quite true, the current implementation uses the time of last > build... but it should be the time of last event, and I will probably fix > that soon) > > So in reality, you just need to run the periodic indexing... we could > tweak that periodic indexing to have a two layer support, e.g. if there are > orphaned items or no events then run every 8h otherwise run every 7 days... > the UI would need thinking but a two layer support might not be a bad idea > > >> On Wednesday, June 21, 2017 at 6:13:32 PM UTC+10, Stephen Connolly wrote: >>> >>> >>> >>> On 21 June 2017 at 00:19, Michael Neale <[email protected]> wrote: >>> >>>> >>>> >>>> On Wednesday, June 21, 2017 at 4:19:58 PM UTC+10, Stephen Connolly >>>> wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> Periodic triggers >>>>>> >>>>>> you want "periodically unless otherwise run" to be something like >>>>>> once a day/week depending on how long you can handle a missed event >>>>>> (which >>>>>> should be unlikely) >>>>>> >>>>>> I recommend somewhere between 1 day and 2 weeks >>>>>> >>>>> >>>> Ah gotcha. >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Was this job configuration created by BO? >>>>> >>>> >>>> No - but I will check what it does and what default does - as the >>>> default should be to do 1 to 2 weeks right? >>>> >>> >>> for GitHub / Bitbucket, their events are reasonably reliable, so I think >>> 1 week would be fine... 1 day also >>> >>> for plain Git, it can be harder for people to set up webhooks, so I >>> would think 8h or 1 day as the default >>> >>> >>>> >>>>> >>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Jenkins Users" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>>> Sent from my phone >>>>>> >>>>> -- >>>>> Sent from my phone >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Jenkins Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/45dd6d78-e268-480c-af88-d70e9c279695%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/45dd6d78-e268-480c-af88-d70e9c279695%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e0366f9c-7c07-4475-8f72-9d54843e3789%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
