Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

On Thu 22 Jun 2017 at 04:29, Michael Neale  wrote:

> I saw all jobs disappear in a github org folder that blue ocean created
> previously, when I triggered a scan.
>
> (it also doesn't seem to trigger scans if I add change the pattern, or run
> the wizard again).
>

I need to investigate some of the hacks BO is using.

I suspect this is probably just one deprecated constructor that needs
tweaking


>
> On Thursday, June 22, 2017 at 4:39:30 AM UTC+10, Mark Waite wrote:
>
>> I haven't tried it yet.  I'm configuring the "before" state today and
>> will capture its state, then will deploy the new code tomorrow morning and
>> capture the after state.  I won't do anything to compare those until
>> tomorrow evening or this weekend.
>>
>> Mark Waite
>>
>> On Wed, Jun 21, 2017 at 12:30 PM Stephen Connolly <
>> stephen.al...@gmail.com> wrote:
>>
> How many people have been able to try this so far?
>>>
>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly 
>>> wrote:
>>>
>> If you are chomping at the bit, here are all the binaries:


 https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0

 SHA1 checksums:
 d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
 16da429f09fb585fd1d744809ee22c8d612fb62c
 cloudbees-bitbucket-branch-source.hpi
 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
 a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi

 SHA256 checksums:
 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7
 branch-api.hpi
 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
 cloudbees-bitbucket-branch-source.hpi
 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248
 git.hpi
 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
 github-branch-source.hpi
 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
 mercurial.hpi
 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
 scm-api.hpi

 -Stephen

>>> On 20 June 2017 at 14:29, Stephen Connolly 
 wrote:

>>> OK! Here we are... testing time!
>
> These are the plugins that are being covered: (download links should
> be live in an hour or two)
>
> scm-api 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
> branch-api 2.0.11-alpha-1
> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
> git 3.4.0-alpha-1
> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
> mercurial 2.0-alpha-1
> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
> github-branch-source 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
> cloudbees-bitbucket-branch-source 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>
> Recommended testing procedure:
>
> 1. Set up a throw-away Jenkins running a version similar to your
> production environment *with the pre-upgrade versions of the plugins
> you are using*.
> 2. Set up ideally at least one organization folder and one standalone
> multibranch project building your source code - to a first order you do 
> not
> care if the builds succeed or fail, only that the branches are found.
> 3. Trigger a scan / index of your organization folders and standalone
> multibranch projects.
> 4. Wait for the queue to complete
> 5. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-pre-upgrade.txt
> 6. Upgrade the relevant plugins, restart Jenkins.
> 7. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-post-upgrade.txt
> 8. Trigger a scan / index of your organization folders and standalone
> multibranch projects.
> 9. Wait for the queue to complete
> 10. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-post-rescan.txt
>
> At this point, do a diff between smoke-pre-upgrade.txt and
> smoke-post-rescan.txt
>
> You are looking for three classes of difference:
>
> a. branch jobs that have been rebuilt for no reason (i.e. the revision
> is the same)
> b. branch jobs that have disappeared for no good reason (i.e. the
> branch is still present in the backing scm)
> c. branch jobs that have 

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Neale]

I saw all jobs disappear in a github org folder that blue ocean created 
previously, when I triggered a scan. 

(it also doesn't seem to trigger scans if I add change the pattern, or run 
the wizard again). 

On Thursday, June 22, 2017 at 4:39:30 AM UTC+10, Mark Waite wrote:
>
> I haven't tried it yet.  I'm configuring the "before" state today and will 
> capture its state, then will deploy the new code tomorrow morning and 
> capture the after state.  I won't do anything to compare those until 
> tomorrow evening or this weekend.
>
> Mark Waite
>
> On Wed, Jun 21, 2017 at 12:30 PM Stephen Connolly  > wrote:
>
>> How many people have been able to try this so far?
>>
>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly > > wrote:
>>
>>> If you are chomping at the bit, here are all the binaries:
>>>
>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>>
>>> SHA1 checksums:
>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>> 16da429f09fb585fd1d744809ee22c8d612fb62c  
>>> cloudbees-bitbucket-branch-source.hpi
>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>
>>> SHA256 checksums:
>>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7  
>>> branch-api.hpi
>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03  
>>> cloudbees-bitbucket-branch-source.hpi
>>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
>>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20  
>>> github-branch-source.hpi
>>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c  
>>> mercurial.hpi
>>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481  
>>> scm-api.hpi
>>>
>>> -Stephen
>>>
>>> On 20 June 2017 at 14:29, Stephen Connolly >> > wrote:
>>>
 OK! Here we are... testing time!

 These are the plugins that are being covered: (download links should be 
 live in an hour or two)

 scm-api 2.2.0-alpha-1 
 https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
 branch-api 2.0.11-alpha-1 
 https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
 git 3.4.0-alpha-1 
 https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
 mercurial 2.0-alpha-1 
 https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
 github-branch-source 2.2.0-alpha-1 
 https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
 cloudbees-bitbucket-branch-source 2.2.0-alpha-1 
 https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi

 Recommended testing procedure:

 1. Set up a throw-away Jenkins running a version similar to your 
 production environment *with the pre-upgrade versions of the plugins 
 you are using*.
 2. Set up ideally at least one organization folder and one standalone 
 multibranch project building your source code - to a first order you do 
 not 
 care if the builds succeed or fail, only that the branches are found.
 3. Trigger a scan / index of your organization folders and standalone 
 multibranch projects.
 4. Wait for the queue to complete
 5. Run the script in the system script console: 
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
 save the output to smoke-pre-upgrade.txt
 6. Upgrade the relevant plugins, restart Jenkins.
 7. Run the script in the system script console: 
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
 save the output to smoke-post-upgrade.txt
 8. Trigger a scan / index of your organization folders and standalone 
 multibranch projects.
 9. Wait for the queue to complete
 10. Run the script in the system script console: 
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and 
 save the output to smoke-post-rescan.txt

 At this point, do a diff between smoke-pre-upgrade.txt and 
 smoke-post-rescan.txt

 You are looking for three classes of difference:

 a. branch jobs that have been rebuilt for no reason (i.e. the revision 
 is the same)
 b. branch jobs that have disappeared for no good reason (i.e. the 
 branch is still present in the backing scm)
 c. branch jobs that have suddenly appeared for no good reason (i.e. the 
 branch was there before but not found) [expecting some of these for 
 BitBucket PRs from forks, but only after configuration updated, saved and 
 another rescan performed]

 My expectation is that nobody will have 

Re: 4 month old deleted branches still not removed

[Michael Neale]

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  > 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  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 jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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 jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.com
  
 
 .

 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 jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> 

Jenkis CLI client connection problem over CLI-Port

[Łukasz Zachulski]

Is there a way to pinpoint the thread which holds CLOSE_WAIT connection? 

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/3f78e7ee-95e9-4b0b-81e2-89f64aa103a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

If you cannot get an ideal "before" that's ok... I'm just trying to make it
easier to know if you have and problematic rebuilds... if you can't get it
clean, best is better than none at all

On Wed 21 Jun 2017 at 20:34, Michael Kobit  wrote:

> Will be able to run this through tomorrow or Friday. The before state is
> harder to get because of how we manage onboarding consumers.
>
> On Wed, Jun 21, 2017, 13:39 Mark Waite  wrote:
>
>> I haven't tried it yet.  I'm configuring the "before" state today and
>> will capture its state, then will deploy the new code tomorrow morning and
>> capture the after state.  I won't do anything to compare those until
>> tomorrow evening or this weekend.
>>
>> Mark Waite
>>
>> On Wed, Jun 21, 2017 at 12:30 PM Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> How many people have been able to try this so far?
>>>
>>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
 If you are chomping at the bit, here are all the binaries:


 https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0

 SHA1 checksums:
 d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
 16da429f09fb585fd1d744809ee22c8d612fb62c
 cloudbees-bitbucket-branch-source.hpi
 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
 a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi

 SHA256 checksums:
 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7
 branch-api.hpi
 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
 cloudbees-bitbucket-branch-source.hpi
 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248
 git.hpi
 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
 github-branch-source.hpi
 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
 mercurial.hpi
 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
 scm-api.hpi

 -Stephen

 On 20 June 2017 at 14:29, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

> OK! Here we are... testing time!
>
> These are the plugins that are being covered: (download links should
> be live in an hour or two)
>
> scm-api 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
> branch-api 2.0.11-alpha-1
> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
> git 3.4.0-alpha-1
> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
> mercurial 2.0-alpha-1
> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
> github-branch-source 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
> cloudbees-bitbucket-branch-source 2.2.0-alpha-1
> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>
> Recommended testing procedure:
>
> 1. Set up a throw-away Jenkins running a version similar to your
> production environment *with the pre-upgrade versions of the plugins
> you are using*.
> 2. Set up ideally at least one organization folder and one standalone
> multibranch project building your source code - to a first order you do 
> not
> care if the builds succeed or fail, only that the branches are found.
> 3. Trigger a scan / index of your organization folders and standalone
> multibranch projects.
> 4. Wait for the queue to complete
> 5. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-pre-upgrade.txt
> 6. Upgrade the relevant plugins, restart Jenkins.
> 7. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-post-upgrade.txt
> 8. Trigger a scan / index of your organization folders and standalone
> multibranch projects.
> 9. Wait for the queue to complete
> 10. Run the script in the system script console:
> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
> save the output to smoke-post-rescan.txt
>
> At this point, do a diff between smoke-pre-upgrade.txt and
> smoke-post-rescan.txt
>
> You are looking for three classes of difference:
>
> a. branch jobs that have been rebuilt for no reason (i.e. the revision
> is the same)
> b. branch jobs that have disappeared for no good reason (i.e. the
> branch is still present in the backing scm)
> c. branch jobs 

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

Will be able to run this through tomorrow or Friday. The before state is
harder to get because of how we manage onboarding consumers.

On Wed, Jun 21, 2017, 13:39 Mark Waite  wrote:

> I haven't tried it yet.  I'm configuring the "before" state today and will
> capture its state, then will deploy the new code tomorrow morning and
> capture the after state.  I won't do anything to compare those until
> tomorrow evening or this weekend.
>
> Mark Waite
>
> On Wed, Jun 21, 2017 at 12:30 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> How many people have been able to try this so far?
>>
>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> If you are chomping at the bit, here are all the binaries:
>>>
>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>>
>>> SHA1 checksums:
>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>> 16da429f09fb585fd1d744809ee22c8d612fb62c
>>> cloudbees-bitbucket-branch-source.hpi
>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>
>>> SHA256 checksums:
>>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7
>>> branch-api.hpi
>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
>>> cloudbees-bitbucket-branch-source.hpi
>>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
>>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
>>> github-branch-source.hpi
>>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
>>> mercurial.hpi
>>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
>>> scm-api.hpi
>>>
>>> -Stephen
>>>
>>> On 20 June 2017 at 14:29, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
 OK! Here we are... testing time!

 These are the plugins that are being covered: (download links should be
 live in an hour or two)

 scm-api 2.2.0-alpha-1
 https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
 branch-api 2.0.11-alpha-1
 https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
 git 3.4.0-alpha-1
 https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
 mercurial 2.0-alpha-1
 https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
 github-branch-source 2.2.0-alpha-1
 https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
 cloudbees-bitbucket-branch-source 2.2.0-alpha-1
 https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi

 Recommended testing procedure:

 1. Set up a throw-away Jenkins running a version similar to your
 production environment *with the pre-upgrade versions of the plugins
 you are using*.
 2. Set up ideally at least one organization folder and one standalone
 multibranch project building your source code - to a first order you do not
 care if the builds succeed or fail, only that the branches are found.
 3. Trigger a scan / index of your organization folders and standalone
 multibranch projects.
 4. Wait for the queue to complete
 5. Run the script in the system script console:
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
 save the output to smoke-pre-upgrade.txt
 6. Upgrade the relevant plugins, restart Jenkins.
 7. Run the script in the system script console:
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
 save the output to smoke-post-upgrade.txt
 8. Trigger a scan / index of your organization folders and standalone
 multibranch projects.
 9. Wait for the queue to complete
 10. Run the script in the system script console:
 https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
 save the output to smoke-post-rescan.txt

 At this point, do a diff between smoke-pre-upgrade.txt and
 smoke-post-rescan.txt

 You are looking for three classes of difference:

 a. branch jobs that have been rebuilt for no reason (i.e. the revision
 is the same)
 b. branch jobs that have disappeared for no good reason (i.e. the
 branch is still present in the backing scm)
 c. branch jobs that have suddenly appeared for no good reason (i.e. the
 branch was there before but not found) [expecting some of these for
 BitBucket PRs from forks, but only after configuration updated, saved and
 another rescan performed]

 My expectation is that nobody will have these kinds of issues.

 Also try out the new UI to see what you think.

 

Re: Publish over FTP on Jenkins Pipeline?

[Slide]

I know for sure that the Publish Over family of plugins don't support
pipeline, they need to have some work done to support it.

On Wed, Jun 21, 2017 at 11:26 AM Thiago Carvalho Davila <
thiago.dav...@serpro.gov.br> wrote:

> Hello,
>
> I've been using this Publish Over FTP plugin for some time (
> https://github.com/jenkinsci/publish-over-ftp-plugin​). And I want to
> know if there is compatibility to doing that using jenkins pipeline for a
> declarative pipeline or does it has some other plugin with that feature.
>
> Thanks in advance,
>
> Thiago
> -
>
>
> "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO),
> empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é
> enviada exclusivamente a seu destinatário e pode conter informações
> confidenciais, protegidas por sigilo profissional. Sua utilização
> desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a
> recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente,
> esclarecendo o equívoco."
>
> "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a
> government company established under Brazilian law (5.615/70) -- is
> directed exclusively to its addressee and may contain confidential data,
> protected under professional secrecy rules. Its unauthorized use is illegal
> and may subject the transgressor to the law's penalties. If you're not the
> addressee, please send it back, elucidating the failure."
>
> --
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/e4f66e4d15b0018c595ccaf64f9d27f5dc90%40serpro.gov.br
> 
> .
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVeOw8DbAqsinq_P_gYSMgg%2B5RPqbHfkqisKuVqB4e8DZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Workspace cleanup failing after updating Jenkins 2.65

[t3knoid]

I have another job that uses the same option and is working just fine. The 
one that is failing is a Java application using Maven to build.

On Wednesday, June 21, 2017 at 1:57:36 PM UTC-4, t3knoid wrote:
>
> I recently updated to Jenkins 2.65 and some of my plugins. Now every time 
> I try to build a job that has been working all along, the job fails when 
> trying to clean the workspace. It only happens after every other job. I can 
> get around the issue by restarting the slave service (Windows). This is 
> obviously not a solution. How can I go about checking what is causing the 
> lock on the folder?
>

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/57b026dd-d6f0-4e46-9d68-6a16bf2c4813%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to make sure that any PMD or Findbug warning fails the CI build?

[Rajdeep Biswas]

The expectation is that whenever PMD or FindBug analysis report any 
warning, the CI build should fail. How can I enable that?

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b130e6b3-59c5-48be-b0ef-9c26b05e928b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

multibranch project: repository scan and pipeline libraries

[Arvind Jayaprakash]

I have a github based multibranch project that uses pipeline libraries.

Triggering the scan of a repository (either manually or through a schedule) 
rebuilds all open branches and pull requests if there has been a change 
made to the pipeline code even if no change has happened on the main 
repository that the project. This behaviour causes problems as a change 
made to the pipeline library can now cause a rebuild of all branches and 
pull requests in hundreds of projects. Is there a way by which we can 
configure a multibranch project in such a way that changes made to pipeline 
libraries do not cause a rebuild when a scan is triggered?

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/bc182cff-df6c-40ca-aa32-4cc5b005a861%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Workspace cleanup failing after updating Jenkins 2.65

[Francis Refol]

It's definitely java.exe. I see a hold on that folder using a utility
called handle.exe
 from
Sysinternals. I am troubleshooting now. I am getting around the problem by
not using "Delete workspace before build starts" option and setting my
Subversion setting to "Always check out a fresh copy." This essentially is
the same as deleting the workspace. The odd thing is that the hold is only
on the folder and not the files that are in the folder. That's why the
"Delete workspace before build starts fails" because it also tries to
remove the job's workspace folder.

On Wed, Jun 21, 2017 at 3:04 PM, Mark Waite 
wrote:

> Interesting that it only happens every other job.
>
> You might consider https://superuser.com/questions/117902/find-out-
> which-process-is-locking-a-file-or-folder-in-windows as a starting point
> to confirm that the process locking the file (or directory) is java.exe
> that is running Jenkins.  If it is not, then whatever process is holding
> the lock is the one you'll need to stop at the end of the job.
>
> If the lock is held by the java.exe which is running Jenkins, then I think
> you'll need to bisect the changes from what was working previously to now,
> so that you can identify the plugin (or core) that introduced the change.
> Once you've isolated it, then report a bug on that component.
>
> Mark Waite
>
> On Wed, Jun 21, 2017 at 11:57 AM t3knoid  wrote:
>
>> I recently updated to Jenkins 2.65 and some of my plugins. Now every time
>> I try to build a job that has been working all along, the job fails when
>> trying to clean the workspace. It only happens after every other job. I can
>> get around the issue by restarting the slave service (Windows). This is
>> obviously not a solution. How can I go about checking what is causing the
>> lock on the folder?
>>
>> --
>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jenkinsci-users/ed2ab916-7923-4355-9b3f-
>> 2e625de0d360%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-users/RCbxvLaN_ls/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/CAO49JtHiAz%3DHf5P%3DAbG8P%
> 2BZZvj7sGMU9pKSyPJ2%3DBa8%3DVMU2hA%40mail.gmail.com
> 
> .
>
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAL-k20XHeE%3DCzDg-gw%2Bdb6sSQksnWBV_-%3DdZ-KPfi18anAfLww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Workspace cleanup failing after updating Jenkins 2.65

[Mark Waite]

Interesting that it only happens every other job.

You might consider
https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows
as
a starting point to confirm that the process locking the file (or
directory) is java.exe that is running Jenkins.  If it is not, then
whatever process is holding the lock is the one you'll need to stop at the
end of the job.

If the lock is held by the java.exe which is running Jenkins, then I think
you'll need to bisect the changes from what was working previously to now,
so that you can identify the plugin (or core) that introduced the change.
Once you've isolated it, then report a bug on that component.

Mark Waite

On Wed, Jun 21, 2017 at 11:57 AM t3knoid  wrote:

> I recently updated to Jenkins 2.65 and some of my plugins. Now every time
> I try to build a job that has been working all along, the job fails when
> trying to clean the workspace. It only happens after every other job. I can
> get around the issue by restarting the slave service (Windows). This is
> obviously not a solution. How can I go about checking what is causing the
> lock on the folder?
>
> --
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/ed2ab916-7923-4355-9b3f-2e625de0d360%40googlegroups.com
> 
> .
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHiAz%3DHf5P%3DAbG8P%2BZZvj7sGMU9pKSyPJ2%3DBa8%3DVMU2hA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Mark Waite]

I haven't tried it yet.  I'm configuring the "before" state today and will
capture its state, then will deploy the new code tomorrow morning and
capture the after state.  I won't do anything to compare those until
tomorrow evening or this weekend.

Mark Waite

On Wed, Jun 21, 2017 at 12:30 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> How many people have been able to try this so far?
>
> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> If you are chomping at the bit, here are all the binaries:
>>
>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>>
>> SHA1 checksums:
>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>> 16da429f09fb585fd1d744809ee22c8d612fb62c
>> cloudbees-bitbucket-branch-source.hpi
>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>
>> SHA256 checksums:
>> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7
>> branch-api.hpi
>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
>> cloudbees-bitbucket-branch-source.hpi
>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
>> github-branch-source.hpi
>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
>> mercurial.hpi
>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
>> scm-api.hpi
>>
>> -Stephen
>>
>> On 20 June 2017 at 14:29, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> OK! Here we are... testing time!
>>>
>>> These are the plugins that are being covered: (download links should be
>>> live in an hour or two)
>>>
>>> scm-api 2.2.0-alpha-1
>>> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
>>> branch-api 2.0.11-alpha-1
>>> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
>>> git 3.4.0-alpha-1
>>> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
>>> mercurial 2.0-alpha-1
>>> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
>>> github-branch-source 2.2.0-alpha-1
>>> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
>>> cloudbees-bitbucket-branch-source 2.2.0-alpha-1
>>> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>>>
>>> Recommended testing procedure:
>>>
>>> 1. Set up a throw-away Jenkins running a version similar to your
>>> production environment *with the pre-upgrade versions of the plugins
>>> you are using*.
>>> 2. Set up ideally at least one organization folder and one standalone
>>> multibranch project building your source code - to a first order you do not
>>> care if the builds succeed or fail, only that the branches are found.
>>> 3. Trigger a scan / index of your organization folders and standalone
>>> multibranch projects.
>>> 4. Wait for the queue to complete
>>> 5. Run the script in the system script console:
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>>> save the output to smoke-pre-upgrade.txt
>>> 6. Upgrade the relevant plugins, restart Jenkins.
>>> 7. Run the script in the system script console:
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>>> save the output to smoke-post-upgrade.txt
>>> 8. Trigger a scan / index of your organization folders and standalone
>>> multibranch projects.
>>> 9. Wait for the queue to complete
>>> 10. Run the script in the system script console:
>>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>>> save the output to smoke-post-rescan.txt
>>>
>>> At this point, do a diff between smoke-pre-upgrade.txt and
>>> smoke-post-rescan.txt
>>>
>>> You are looking for three classes of difference:
>>>
>>> a. branch jobs that have been rebuilt for no reason (i.e. the revision
>>> is the same)
>>> b. branch jobs that have disappeared for no good reason (i.e. the branch
>>> is still present in the backing scm)
>>> c. branch jobs that have suddenly appeared for no good reason (i.e. the
>>> branch was there before but not found) [expecting some of these for
>>> BitBucket PRs from forks, but only after configuration updated, saved and
>>> another rescan performed]
>>>
>>> My expectation is that nobody will have these kinds of issues.
>>>
>>> Also try out the new UI to see what you think.
>>>
>>> Please report back your testing results either way. Don't forget to
>>> report back your UI feedback too ;-)
>>>
>>> After doing that test in a throw-away Jenkins, you can *optionally*
>>> repeat the test on a *more* production*-like* (emphasis on being
>>> production-like not production) instance... but this is code that has 

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

How many people have been able to try this so far?

On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> If you are chomping at the bit, here are all the binaries:
>
> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0
>
> SHA1 checksums:
> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
> 16da429f09fb585fd1d744809ee22c8d612fb62c
> cloudbees-bitbucket-branch-source.hpi
> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>
> SHA256 checksums:
> 858ce20992c3f179b850c51297084b11fe7c4c173cf6d4d2e07bbfebf3e7
> branch-api.hpi
> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
> cloudbees-bitbucket-branch-source.hpi
> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248  git.hpi
> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
> github-branch-source.hpi
> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
> mercurial.hpi
> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
> scm-api.hpi
>
> -Stephen
>
> On 20 June 2017 at 14:29, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> OK! Here we are... testing time!
>>
>> These are the plugins that are being covered: (download links should be
>> live in an hour or two)
>>
>> scm-api 2.2.0-alpha-1
>> https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi
>> branch-api 2.0.11-alpha-1
>> https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi
>> git 3.4.0-alpha-1
>> https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi
>> mercurial 2.0-alpha-1
>> https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi
>> github-branch-source 2.2.0-alpha-1
>> https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi
>> cloudbees-bitbucket-branch-source 2.2.0-alpha-1
>> https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi
>>
>> Recommended testing procedure:
>>
>> 1. Set up a throw-away Jenkins running a version similar to your
>> production environment *with the pre-upgrade versions of the plugins you
>> are using*.
>> 2. Set up ideally at least one organization folder and one standalone
>> multibranch project building your source code - to a first order you do not
>> care if the builds succeed or fail, only that the branches are found.
>> 3. Trigger a scan / index of your organization folders and standalone
>> multibranch projects.
>> 4. Wait for the queue to complete
>> 5. Run the script in the system script console:
>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>> save the output to smoke-pre-upgrade.txt
>> 6. Upgrade the relevant plugins, restart Jenkins.
>> 7. Run the script in the system script console:
>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>> save the output to smoke-post-upgrade.txt
>> 8. Trigger a scan / index of your organization folders and standalone
>> multibranch projects.
>> 9. Wait for the queue to complete
>> 10. Run the script in the system script console:
>> https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>> save the output to smoke-post-rescan.txt
>>
>> At this point, do a diff between smoke-pre-upgrade.txt and
>> smoke-post-rescan.txt
>>
>> You are looking for three classes of difference:
>>
>> a. branch jobs that have been rebuilt for no reason (i.e. the revision is
>> the same)
>> b. branch jobs that have disappeared for no good reason (i.e. the branch
>> is still present in the backing scm)
>> c. branch jobs that have suddenly appeared for no good reason (i.e. the
>> branch was there before but not found) [expecting some of these for
>> BitBucket PRs from forks, but only after configuration updated, saved and
>> another rescan performed]
>>
>> My expectation is that nobody will have these kinds of issues.
>>
>> Also try out the new UI to see what you think.
>>
>> Please report back your testing results either way. Don't forget to
>> report back your UI feedback too ;-)
>>
>> After doing that test in a throw-away Jenkins, you can *optionally*
>> repeat the test on a *more* production*-like* (emphasis on being
>> production-like not production) instance... but this is code that has not
>> yet completed code review (hence -alpha-1 not -beta-1) so it is at your own
>> risk. There are additional issues to be aware when using more
>> production-like environment:
>>
>> a. You may have builds that were assuming branches were full clones, now
>> the refspec is tightly reduced to minimize clone time. If you need a full
>> clone you will need to add the "Advanced Clone" behaviour.
>> b. Mercurial repositories on Bitbucket Cloud do not support 

Publish over FTP on Jenkins Pipeline?

[Thiago Carvalho Davila]

Hello,

I've been using this Publish Over FTP plugin for some time 
(https://github.com/jenkinsci/publish-over-ftp-plugin​). And I want to know if 
there is compatibility to doing that using jenkins pipeline for a declarative 
pipeline or does it has some other plugin with that feature.

Thanks in advance,

Thiago

-


"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa 
pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada 
exclusivamente a seu destinatário e pode conter informações confidenciais, 
protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e 
sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, 
por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a 
government company established under Brazilian law (5.615/70) -- is directed 
exclusively to its addressee and may contain confidential data, protected under 
professional secrecy rules. Its unauthorized use is illegal and may subject the 
transgressor to the law's penalties. If you're not the addressee, please send 
it back, elucidating the failure."

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e4f66e4d15b0018c595ccaf64f9d27f5dc90%40serpro.gov.br.
For more options, visit https://groups.google.com/d/optout.

Workspace cleanup failing after updating Jenkins 2.65

[t3knoid]

I recently updated to Jenkins 2.65 and some of my plugins. Now every time I 
try to build a job that has been working all along, the job fails when 
trying to clean the workspace. It only happens after every other job. I can 
get around the issue by restarting the slave service (Windows). This is 
obviously not a solution. How can I go about checking what is causing the 
lock on the folder?

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/ed2ab916-7923-4355-9b3f-2e625de0d360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Runing Groovy scripts on Jenkins on Master

[jerome]

if you are into a pipeline, you can swap node by using
node("master")
{
...
}


-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/df913a9a-b259-42a8-9032-26cb6457d520%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: REST API to create Credentials in jenkins

[Dayanand Lature]

Hello Venkata,

Could you please help me for
create job
create user
create group
etc..
all the above stuff by using java code.

Thanks,
Dayanand

On Saturday, 1 August 2015 03:13:50 UTC+5:30, Venkata Naga Rakesh wrote:
>
> Hello,
>
> I have created jenkins job through API and now trying to figure out how to 
> create credentials through the API. 
>
> Any help would be appreciated.
>
> Thanks,
>

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/47fdfe4d-6d7a-4599-ad47-5a3110200a75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [EXTERNAL] - Runing Groovy scripts on Jenkins on Master

[Dirk Heinrichs]

Am 21.06.2017 um 13:59 schrieb Oparlescu Vlad:

> It seems that due to the fact that I use system groovy script build
> option, the build still runs on a slave ?
> Is there a mistake or a setting that must be made on the master ?

The *job* may run on a slave, but the *script* (since it's a system
Groovy script) runs in the masters JVM.

HTH...

Dirk
-- 
*Dirk Heinrichs*
Senior Systems Engineer, Delivery Pipeline
OpenText^TM Discovery | Recommind
*Email*: dirk.heinri...@recommind.com 
*Website*: www.recommind.de 

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer John Marshall Doolittle, Gordon
Davies, Roger Illing, Registergericht Amtsgericht Bonn, Registernummer
HRB 10646

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/620d6f5f-bb79-9a28-f604-d2c6e7ab3f81%40opentext.com.
For more options, visit https://groups.google.com/d/optout.

Runing Groovy scripts on Jenkins on Master

[Oparlescu Vlad]

Hello Jenkins users,

I created a groovy script where I generate some values that I'm reading 
from the builds.
It seems that due to the fact that I use system groovy script build option, 
the build still runs on a slave ?
Is there a mistake or a setting that must be made on the master ?


Building remotely on frv0021g  in 
workspace D:\MB_MFA2_18_SCU\JenkinsWorkspace\workspace\__PMT Collect K1 and 
K1Lite
FATAL: T:\040_PMT_SwEMT\Jenkins\KPIs\EUROPE\K1.csv (The system cannot find the 
path specified)
java.io.FileNotFoundException: T:\040_PMT_SwEMT\Jenkins\KPIs\EUROPE\K1.csv (The 
system cannot find the path specified)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileWriter.(FileWriter.java:107)


*Shouldn't have run exclusively on the master machine and not have this error?*


Thank you,
Vlad

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b4c0d2a0-ea70-4cba-8ed7-c6d28159f377%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Configure Compiler Warining Priority

[Ullrich Hafner]

This is not possible yet. You can create a PR that changes the parser if your 
mapping makes sense for every one.

> Am 20.06.2017 um 10:13 schrieb Angel Yanev :
> 
> Hello everybody,
> 
> I am wondering what is the way to configure which warning are with priority 
> Normal/High/Low. The GNU C Compiler Warnings are all with priority Normal for 
> me.
> I would like to set warning such as out of bounds with High priority. Do you 
> know how to configure this ?
> 
> I am currently using the Warning plugin v4.58.
> 
> Thank you!
> 
> Best Regards,
> Angel Yanev
> 
> --
> 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 jenkinsci-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/69647981-730d-40d7-9329-7d9e9ec60781%40googlegroups.com
>  
> .
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/9E3B6770-102D-4504-83EE-118A426BB71A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: 4 month old deleted branches still not removed

[Stephen Connolly]

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 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  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 jenkinsci-use...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/25632742-
>> 1301-4478-9d8d-7178d496e876%40googlegroups.com
>> 
>> .
>> 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 jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/45dd6d78-e268-480c-af88-d70e9c279695%40googlegroups.
> com
> 
> .
>
> 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 

Jenkis CLI client connection problem over CLI-Port

[Łukasz Zachulski]

Hello,

I'm using Jenkins 1.642.1 and since 2 weeks I'm seeing recurring problems 
with Jenkins CLI client.
Precisely the problem is with CLI client not able to correctly establish 
connection with Jenkins master and get an response. It looks like the 
connection hangs.

Checking connections with `netstat` I can noticed that clients can 
establish connection. 


# netstat -an  | grep 47207
10.21.18.38.4720710.21.16.206.32910   14720  0 49209  0 
CLOSE_WAIT <--- cli already finished running
  *.47207  *.*0  0 49152  0 LISTEN
10.21.18.38.4720710.21.16.200.45514   49640  0 49617  0 
ESTABLISHED<--- hanging cli connection

However what bother me is the single one connection which is in CLOSE_WAIT 
state. CLI client which initialized this connection already exit, but for 
some reason Jenkins master can't close the socket.

Right now the only workarounds that works for me is:
- reset CLI-Port or
- restart Jenkins master

Any idea what going on? And is there a solution or better workaround?


ps. Jenkins and CLI client have been working perfectly well for over a 1,5 
years. During that time we haven't change Jenkins version or its plug-ins.

Cheers,
Lukasz.

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/8384d5a2-2bab-4f31-9a8d-cbf77010616d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Michael Neale]

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  > 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 jenkinsci-use...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com
>  
> 
> .
> 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 jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.com
>>  
>> 
>> .
>>
>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/45dd6d78-e268-480c-af88-d70e9c279695%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Stephen Connolly]

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. (would like to correct those... probably want a
JIRA for that anyway)

The intent is that periodically unless otherwise run should be acting as a
backup... can probably make it default to on. Can you file a JIRA


>
>
> On Wednesday, June 21, 2017 at 6:03:03 PM UTC+10, Michael Neale wrote:
>>
>> 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 be clear it is the following right?
>>
>>
>> 
>>
>>
>>
>>
>>
>> --
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/70f52071-5f57-4205-835b-8bb27c21d1ba%40googlegroups.
> com
> 
> .
>
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyk5bki2dPkLYNfQ3w__qH5g8JBx4tP6_tjKsq97ea8gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Stephen Connolly]

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 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 jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%
 40googlegroups.com
 
 .
 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.
> com
> 
> .
>
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwy5V0TB86DX_%2BWfzZ7i_iGzS8w3LLzsN%3Dq2YW5CQeW0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Michael Neale]

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 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 be clear it is the following right? 
>
>
> 
>
>
>
>
>
>

-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/70f52071-5f57-4205-835b-8bb27c21d1ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Michael Neale]

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 be clear it is the following right? 







-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c106e17f-e1a5-4f26-96c2-6aef60e7beb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Michael Neale]

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?  

>
>
>> -- 
>>> 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 jenkinsci-use...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/6198792c-e664-40f8-95c3-f3650ba74d38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Stephen Connolly]

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.
>

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


>
>>
>> Orphaned items are only removed on a full scan.
>>
>
>> New items are added by events, so adding new branches will not be a sign
>> that you are getting full scans
>>
>
> What decides how often there is a full scan?
>

User configuration

-- 
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxk%2BgZ5MMzx7qvKuu4ftbCSj_%3DzQfedCGUYhjyVKF%3DRZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 4 month old deleted branches still not removed

[Stephen Connolly]

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 log link - then not for 2 months or so. What
>> triggers that? All the settings are stock.
>>
>
> 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
>
>
>>
>>>
>>> Orphaned items are only removed on a full scan.
>>>
>>
>>> New items are added by events, so adding new branches will not be a sign
>>> that you are getting full scans
>>>
>>
>> What decides how often there is a full scan?
>>
>
> User configuration
>

Was this job configuration created by BO?


> --
>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/25632742-1301-4478-9d8d-7178d496e876%40googlegroups.com
>> 
>> .
>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMyit6tjpS4SqCvAa8V0EM_d%2B4yucq5Q7kG2KoPu5zvU1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.