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 >
On 21 June 2017 at 01:16, Michael Neale 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 bran
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).
On Wednesday, June 21, 2017 at 6:13:32 PM UTC+10, Stephen Connolly wrote:
>
>
>
> On 21 June 2017 at 00:19, Michael Neale > wro
On 21 June 2017 at 01:04, Michael Neale wrote:
> reading the docs for folders, perhaps there is a bug from a bad
> assumption. a github event will not trigger a scan like the author of the
> folders plugin implies so it still needs to have this set even for
> github
>
Link to the docs please
On 21 June 2017 at 00:19, Michael Neale 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 mi
reading the docs for folders, perhaps there is a bug from a bad assumption.
a github event will not trigger a scan like the author of the folders
plugin implies so it still needs to have this set even for github
On Wednesday, June 21, 2017 at 6:03:03 PM UTC+10, Michael Neale wrote:
>
> OK on
OK on looking further - MBPs created by classic don't have this set - which
seems wrong - worthy of a ticket?
Ones created by blue ocean do have it set (1 day, as it turns out) via the
github org folder.
So this explains it, but leaves the issue of the default for creation being
wrong.
to b
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
On Wed 21 Jun 2017 at 06:54, Michael Neale wrote:
>
>
> On Wednesday, June 21, 2017 at 3:50:06 PM UTC+10, Stephen Connolly wrote:
>>
>>
>> How often is a full scan?
>>
>
> Is that is from the scan log link - then not for 2 months or so. What
> triggers that? All the settings are stock.
>
Periodi
On Wed 21 Jun 2017 at 07:18, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Wed 21 Jun 2017 at 06:54, Michael Neale wrote:
>
>>
>>
>> On Wednesday, June 21, 2017 at 3:50:06 PM UTC+10, Stephen Connolly wrote:
>>>
>>>
>>> How often is a full scan?
>>>
>>
>> Is that is from the scan
On Wednesday, June 21, 2017 at 3:50:06 PM UTC+10, Stephen Connolly wrote:
>
>
> How often is a full scan?
>
Is that is from the scan log link - then not for 2 months or so. What
triggers that? All the settings are stock.
>
> Orphaned items are only removed on a full scan.
>
> New items ar
On Wed 21 Jun 2017 at 06:17, Michael Neale wrote:
> github? polling or webhooks?
>
> The "scan respotory log" doesn't show anything recent (but new branches
> are still being built) - does yours show anything different?
>
How often is a full scan?
Orphaned items are only removed on a full scan.
github? polling or webhooks?
The "scan respotory log" doesn't show anything recent (but new branches are
still being built) - does yours show anything different?
This seems a recent thing (well a change in last few months) or else we
would have > 4 month old dead branches.
On Wednesday, 21
Correct. I have some test jobs which intentionally create and destroy
branches as part of their testing, and those branches correctly disappear
shortly after the branch deletion is detected.
On Tue, Jun 20, 2017 at 8:34 PM Michael Neale wrote:
> and obviously you aren't seeing deleted branches
and obviously you aren't seeing deleted branches still show up without
being cleaned up?
On Wednesday, June 21, 2017 at 12:23:59 PM UTC+10, Mark Waite wrote:
>
> Yes, that's how mine is configured.
>
> On Tue, Jun 20, 2017 at 8:21 PM Michael Neale > wrote:
>
>> Yes I suspected that - it is the
Yes, that's how mine is configured.
On Tue, Jun 20, 2017 at 8:21 PM Michael Neale wrote:
> Yes I suspected that - it is the default that you get when you create a
> new project (see below screen shot). Is this is what yours is?
>
> This multibranch project has been around for a while - and it on
Yes I suspected that - it is the default that you get when you create a new
project (see below screen shot). Is this is what yours is?
This multibranch project has been around for a while - and it only recently
started showing this behavior (recently as 4 months) so I suspect something
changed
There is a configuration setting, "Orphaned Item Strategy", in the
multi-branch pipeline job definition and in the GitHub Organization Folders
definition which sets a retention period for jobs associated with deleted
branches. Mine is set to Discard old items, with a retention period of 0
days.
I
18 matches
Mail list logo
