Re: [Adoption] gerrit-code-review-plugin

[Luca Milanesio]

> On 26 Sep 2022, at 21:51, 'Réda Housni Alaoui' via Jenkins Developers 
>  wrote:
> 
> Great. 
> 
> Will you review my currently open changes? Or do you expect me to merge them 
> myself?

Typically we don’t allow self-review / self-approval in Gerrit, I’ll have a 
look at them.

Luca.

> 
> On Monday, September 26, 2022 at 10:46:23 PM UTC+2 lucamilanesio wrote:
> 
>> On 26 Sep 2022, at 14:01, 'Réda Housni Alaoui' via Jenkins Developers 
>> > > wrote:
>> 
>> Thank you !
>> 
>> On Monday, September 26, 2022 at 2:31:34 PM UTC+2 lucamilanesio wrote:
>> 
>>> On 26 Sep 2022, at 12:57, 'Réda Housni Alaoui' via Jenkins Developers 
>>> > wrote:
>>> 
>>> Hello Luca !
>>> 
>>> > Where di you see this status?
>>> 
>>> Sorry I wrongly copy pasted another adoption request :X
>>> 
>>> > I’d be happy to give you more permissions and reviews assigned on the 
>>> > project: I definitely need more help to develop it.
>>> > However, I’d like to keep the ownership of the plugin.
>>> > What do you think?
>>> 
>>> I created this adoption request because there has been no new commit since 
>>> December 2021. I thought you had no more time for this plugin (because of 
>>> the 1000 other plugins you lead :D ) .
>>> I only want to see my changes reviewed and eventually merged when it make 
>>> sense :)
>>> 
>>> So yes, please keep the ownership and thank you for your efforts and this 
>>> wonderful plugin !
>> 
>> I’ll add you Code-Review +2 permissions on review.gerrithub.io 
>> , I trust your reliability and dedication to 
>> OpenSource, thanks for all your help so far.
> 
> All done, you can now approve changes on the plugin.
> 
> Luca.
> 
> 
>> 
>>> 
>>> It'd be an honor to have more permission on the plugin. But please note 
>>> that I am not sure to have enough bandwidth to review other people 
>>> contributions.
>> 
>> I’ll definitely appreciate any additional help you could provide, without 
>> commitments.
>> 
>> Luca.
>> 
>> 
>>> 
>>> On Monday, September 26, 2022 at 1:45:47 PM UTC+2 lucamilanesio wrote:
>>> 
>>> 
 On 26 Sep 2022, at 12:27, 'Réda Housni Alaoui' via Jenkins Developers 
 > wrote:
 
 Hi,
>>> 
>>> Hi Reda,
>>> I am the owner of the plugin, thanks for offering your help to work on the 
>>> plugin.
>>> 
>>> I’d be delighted to have you onboard with me, you also contributed a lot to 
>>> other of my plugins, including the Jira integration for Gerrit Code Review.
>>> 
  
 I would like to adopt a plugin:
 Link: https://github.com/jenkinsci/gerrit-code-review-plugin 
 
 Pull requests: 
 https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526905 
 
 https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/527041 
 
 https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526993 
 
 https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526430 
 
>>> 
>>> We do the reviews on GerritHub.io , see the open 
>>> changes at:
>>> https://review.gerrithub.io/q/project:jenkinsci/gerrit-code-review-plugin+status:open
>>>  
>>> 
>>> 
>>> I’ll add my reviews today.
>>> 
 Status: for adoption
>>> 
>>> Where di you see this status?
>>> 
 GitHub Username: reda-alaoui 
 Jenkins Infrastructure ID: reda_alaoui
 Best regards
>>> 
>>> I’d be happy to give you more permissions and reviews assigned on the 
>>> project: I definitely need more help to develop it.
>>> However, I’d like to keep the ownership of the plugin.
>>> 
>>> What do you think?
>>> 
>>> Luca.
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-de...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/d56ba900-2bcf-474b-a9e7-4773b813f89bn%40googlegroups.com
>>>  
>>> .
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com 
>> .
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/d550ba57-6c36-4e15-b7d2-a7

Re: [Adoption] gerrit-code-review-plugin

[Luca Milanesio]

> On 26 Sep 2022, at 14:01, 'Réda Housni Alaoui' via Jenkins Developers 
>  wrote:
> 
> Thank you !
> 
> On Monday, September 26, 2022 at 2:31:34 PM UTC+2 lucamilanesio wrote:
> 
>> On 26 Sep 2022, at 12:57, 'Réda Housni Alaoui' via Jenkins Developers 
>> > > wrote:
>> 
>> Hello Luca !
>> 
>> > Where di you see this status?
>> 
>> Sorry I wrongly copy pasted another adoption request :X
>> 
>> > I’d be happy to give you more permissions and reviews assigned on the 
>> > project: I definitely need more help to develop it.
>> > However, I’d like to keep the ownership of the plugin.
>> > What do you think?
>> 
>> I created this adoption request because there has been no new commit since 
>> December 2021. I thought you had no more time for this plugin (because of 
>> the 1000 other plugins you lead :D ) .
>> I only want to see my changes reviewed and eventually merged when it make 
>> sense :)
>> 
>> So yes, please keep the ownership and thank you for your efforts and this 
>> wonderful plugin !
> 
> I’ll add you Code-Review +2 permissions on review.gerrithub.io 
> , I trust your reliability and dedication to 
> OpenSource, thanks for all your help so far.

All done, you can now approve changes on the plugin.

Luca.

> 
>> 
>> It'd be an honor to have more permission on the plugin. But please note that 
>> I am not sure to have enough bandwidth to review other people contributions.
> 
> I’ll definitely appreciate any additional help you could provide, without 
> commitments.
> 
> Luca.
> 
> 
>> 
>> On Monday, September 26, 2022 at 1:45:47 PM UTC+2 lucamilanesio wrote:
>> 
>> 
>>> On 26 Sep 2022, at 12:27, 'Réda Housni Alaoui' via Jenkins Developers 
>>> > wrote:
>>> 
>>> Hi,
>> 
>> Hi Reda,
>> I am the owner of the plugin, thanks for offering your help to work on the 
>> plugin.
>> 
>> I’d be delighted to have you onboard with me, you also contributed a lot to 
>> other of my plugins, including the Jira integration for Gerrit Code Review.
>> 
>>>  
>>> I would like to adopt a plugin:
>>> Link: https://github.com/jenkinsci/gerrit-code-review-plugin 
>>> 
>>> Pull requests: 
>>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526905 
>>> 
>>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/527041 
>>> 
>>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526993 
>>> 
>>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526430 
>>> 
>> 
>> We do the reviews on GerritHub.io , see the open 
>> changes at:
>> https://review.gerrithub.io/q/project:jenkinsci/gerrit-code-review-plugin+status:open
>>  
>> 
>> 
>> I’ll add my reviews today.
>> 
>>> Status: for adoption
>> 
>> Where di you see this status?
>> 
>>> GitHub Username: reda-alaoui 
>>> Jenkins Infrastructure ID: reda_alaoui
>>> Best regards
>> 
>> I’d be happy to give you more permissions and reviews assigned on the 
>> project: I definitely need more help to develop it.
>> However, I’d like to keep the ownership of the plugin.
>> 
>> What do you think?
>> 
>> Luca.
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/d56ba900-2bcf-474b-a9e7-4773b813f89bn%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/d550ba57-6c36-4e15-b7d2-a7a31eda1dden%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the

Re: [Adoption] gerrit-code-review-plugin

[Luca Milanesio]

> On 26 Sep 2022, at 12:57, 'Réda Housni Alaoui' via Jenkins Developers 
>  wrote:
> 
> Hello Luca !
> 
> > Where di you see this status?
> 
> Sorry I wrongly copy pasted another adoption request :X
> 
> > I’d be happy to give you more permissions and reviews assigned on the 
> > project: I definitely need more help to develop it.
> > However, I’d like to keep the ownership of the plugin.
> > What do you think?
> 
> I created this adoption request because there has been no new commit since 
> December 2021. I thought you had no more time for this plugin (because of the 
> 1000 other plugins you lead :D ) .
> I only want to see my changes reviewed and eventually merged when it make 
> sense :)
> 
> So yes, please keep the ownership and thank you for your efforts and this 
> wonderful plugin !

I’ll add you Code-Review +2 permissions on review.gerrithub.io 
, I trust your reliability and dedication to 
OpenSource, thanks for all your help so far.

> 
> It'd be an honor to have more permission on the plugin. But please note that 
> I am not sure to have enough bandwidth to review other people contributions.

I’ll definitely appreciate any additional help you could provide, without 
commitments.

Luca.

> 
> On Monday, September 26, 2022 at 1:45:47 PM UTC+2 lucamilanesio wrote:
> 
> 
>> On 26 Sep 2022, at 12:27, 'Réda Housni Alaoui' via Jenkins Developers 
>> > > wrote:
>> 
>> Hi,
> 
> Hi Reda,
> I am the owner of the plugin, thanks for offering your help to work on the 
> plugin.
> 
> I’d be delighted to have you onboard with me, you also contributed a lot to 
> other of my plugins, including the Jira integration for Gerrit Code Review.
> 
>>  
>> I would like to adopt a plugin:
>> Link: https://github.com/jenkinsci/gerrit-code-review-plugin 
>> 
>> Pull requests: 
>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526905 
>> 
>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/527041 
>> 
>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526993 
>> 
>> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526430 
>> 
> 
> We do the reviews on GerritHub.io , see the open 
> changes at:
> https://review.gerrithub.io/q/project:jenkinsci/gerrit-code-review-plugin+status:open
>  
> 
> 
> I’ll add my reviews today.
> 
>> Status: for adoption
> 
> Where di you see this status?
> 
>> GitHub Username: reda-alaoui 
>> Jenkins Infrastructure ID: reda_alaoui
>> Best regards
> 
> I’d be happy to give you more permissions and reviews assigned on the 
> project: I definitely need more help to develop it.
> However, I’d like to keep the ownership of the plugin.
> 
> What do you think?
> 
> Luca.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/d56ba900-2bcf-474b-a9e7-4773b813f89bn%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/29BC0054-2995-433F-9D66-D06662ACD3F0%40gmail.com.

Re: [Adoption] gerrit-code-review-plugin

[Luca Milanesio]

> On 26 Sep 2022, at 12:27, 'Réda Housni Alaoui' via Jenkins Developers 
>  wrote:
> 
> Hi,

Hi Reda,
I am the owner of the plugin, thanks for offering your help to work on the 
plugin.

I’d be delighted to have you onboard with me, you also contributed a lot to 
other of my plugins, including the Jira integration for Gerrit Code Review.

>  
> I would like to adopt a plugin:
> Link: https://github.com/jenkinsci/gerrit-code-review-plugin 
> 
> Pull requests: 
> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526905 
> 
> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/527041 
> 
> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526993 
> 
> https://review.gerrithub.io/c/jenkinsci/gerrit-code-review-plugin/+/526430 
> 
We do the reviews on GerritHub.io , see the open changes 
at:
https://review.gerrithub.io/q/project:jenkinsci/gerrit-code-review-plugin+status:open
 


I’ll add my reviews today.

> Status: for adoption

Where di you see this status?

> GitHub Username: reda-alaoui 
> Jenkins Infrastructure ID: reda_alaoui
> Best regards

I’d be happy to give you more permissions and reviews assigned on the project: 
I definitely need more help to develop it.
However, I’d like to keep the ownership of the plugin.

What do you think?

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/F83815E9-41B9-426D-A2B1-99AA0B3410FE%40gmail.com.

Re: gerrit-code-review-plugin: Gerrit checks plugin has been deprecated

[Luca Milanesio]

Possibly a question for the repo-discuss mailing list?

The Checks plugin isn't a mandatory requirement of the Gerrit Code Review 
plugin: if you have it, it can be used. If you don’t have it, you’ll keep on 
using the labels.

HTH

Luca.

> On 3 Dec 2021, at 15:49, 'Wade Carpenter' via Jenkins Developers 
>  wrote:
> 
> It's about the gerrit-code-review-plugin jenkins plugin, 
> https://github.com/jenkinsci/gerrit-code-review-plugin#integrating-with-the-gerrit-checks-plugin
>  
> .
>  It's using the now-obsolete gerrit checks plugin to publish the build status 
> back to gerrit. The gerrit change is about restructing the way that CI 
> systems are integrated with gerrit, so this plugin is impacted.
> 
> 
> On Thursday, December 2, 2021 at 8:24:36 PM UTC-8 ga...@gavinmogan.com 
>  wrote:
> I'm sorry but what does this have to do with Jenkins?
> 
> On Thu., Dec. 2, 2021, 8:14 p.m. 'Wade Carpenter' via Jenkins Developers, 
>  > wrote:
> Hi folks,
> 
> (I was torn betwen -dev and -users for this thread, so hopefully I got it 
> right!)
> 
> While I was looking at https://gerrit.googlesource.com/plugins/checks 
>  today, I saw the following:
> 
> DEPRECATION NOTICE
> The Gerrit team at Google has decided to discontinue work on the checks 
> plugin. The recommended solution is Checks UI 
> 
>  which surfaces results from an external CI/analysis system.
> 
> This seems to suggest that either we need to come up with a gerrit 
> "jenkinsci" plugin to provide a checks UI, or consider some other approach. 
> At this point I'm sorta waiting to see which direction 
> gerrit-review.googlesource.com  goes 
> in, but I was also wondering if anyone here has thoughts on this.
> 
> Thanks!
> Wade
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-de...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/0aae5971-4e08-4570-94d8-742ad4deddc7n%40googlegroups.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/239be687-fead-4631-b0a6-e3e3e511f4d3n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/C50181B9-4FB5-46CF-BC6E-C9C2BACAE6B1%40gmail.com.

Re: Password reset not working on issues.jenkins.io

[Luca Milanesio]

> On 8 Sep 2021, at 23:37, Mark Waite  wrote:
> 
> Try the password reset facility from https://beta.accounts.jenkins.io/ 
>  first.  If that does not work for you, 
> then try the password reset facility from https://accounts.jenkins.io/ 
>  .  If that also does not work, then contact me 
> by email at mark.earl.wa...@gmail.com  and 
> I'll assist you with the reset process.
> 
> I'll need to know your Jenkins account username and the email address that 
> you believe is associated with that account.

Yeah, all worked and new release uploaded:

Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.hpi
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.hpi
 (4.9 MB at 547 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.pom
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.pom
 (14 kB at 15 kB/s)
Downloading from maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/maven-metadata.xml
Downloaded from maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/maven-metadata.xml
 (856 B at 2.9 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/maven-metadata.xml
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/maven-metadata.xml
 (808 B at 934 B/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.jar
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7.jar
 (160 kB at 132 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-tests.jar
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-tests.jar
 (39 kB at 31 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-sources.jar
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-sources.jar
 (80 kB at 66 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-test-sources.jar
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-test-sources.jar
 (23 kB at 24 kB/s)
Uploading to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-javadoc.jar
Uploaded to maven.jenkins-ci.org: 
https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/gerrit-code-review/0.4.7/gerrit-code-review-0.4.7-javadoc.jar
 (365 kB at 278 kB/s)
[INFO] 

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time:  46.772 s
[INFO] Finished at: 2021-09-08T23:48:07+01:00
[INFO] 

Thanks a lot for sorting that out.

Luca.

> 
> On Wed, Sep 8, 2021 at 4:28 PM Adam Kaplan  > wrote:
> Perhaps this isn't the right forum for JIRA or accounts.jenkins.io 
>  issues - I'm currently struggling to reset my 
> password. The sign up process confirms that my email and username are already 
> in use. The reset link, however, is not being sent. Is a system down, or is 
> my account otherwise locked?
> 
> Thanks,
> Adam
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/05cd57bf-b9b7-427b-b42d-85c6017f9b77n%40googlegroups.com
>  
> 

[Announce] Gerrit Code Review plugin v0.3.1 is out - supports integration with the Gerrit Trigger Plugin

[Luca Milanesio]

Hi all,
I am pleased to announce that after the Jenkins World 2018 summit in Nice last 
week, the Gerrit Code Review plugin 
(https://wiki.jenkins.io/display/JENKINS/Gerrit+Code+Review+Plugin) has 
received new contributions (thanks Alon) and now support many more use-cases:

Integrates with the Gerrit Trigger Plugin for automating Jenkinsfile simple 
pipelines
Allows posting comments to the source files in Gerrit from a Jenkinsfile 
pipeline step
Fully compliant with the Declarative and Scripting pipelines
Support multiple review labels in a single review step

The release of v0.3.1 is a significant step to bring this new plugin to a whole 
new series of use-cases and opening it to future contributions.

Thanks for everyone involved in reviews, fixes, and contributions. Feel free to 
give it a try and contribute to it.

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/E9B97C53-5077-408F-B8D0-CB84D3DBA896%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins X status

[luca . milanesio]

Sent from my iPhone

> On 13 Apr 2018, at 06:18, Rob Davies  wrote:
> 
> Whilst the Jenkins X JEP proposal is still under consideration -  I thought 
> it would be worthwhile giving a quick summary of where we stand with the 
> project.
> There's actually a great summary of community stats done in a generated blog 
> using jenkins-X but the hlighlights include  integration with Github issues, 
> GitHub Enterprise and Jira. Continued development of BitBucket and Gitea 
> integrations.

Any reason why only commercial Git server products are taken into account for 
integration? Have you Gerrit anywhere in the roadmap?


> We have gained 10 new commiiters and 18 new contributors - which is fantastic 
> - but we would love more! Work is being undertaken on integrating 
> Anhttps://github.com/anchorechore for validation of container images in 
> pipelines. Anchore also have a Jenkins plugin.
> 
> Rob
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/972146ce-6eb3-471f-8b74-d70614e6bb87%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/351DD17E-3E40-4784-A1DF-F59020CE817F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Oh gosh, this is the messy GitHub PRs :-(

I had actually two requests in the pipeline but when you create two PRs in a 
chain ... GitHub messes them up.
Let me fix it manually and re-push.

Luca.

> On 24 Apr 2018, at 09:15, Oleg Nenashev  wrote:
> 
> Hi Luca,
> 
> Thanks for the ping! Access to the repo granted. 
> Regarding the release permissions, something is wrong in 
> https://github.com/jenkins-infra/repository-permissions-updater/pull/670 . It 
> refers another plugin you have created recently, but not Statistics gatherer.
> 
> BR, Oleg
> 
> On Tuesday, April 24, 2018 at 9:33:38 AM UTC+2, lucamilanesio wrote:
> Any updates? The timeout ended yesterday and we got no further feedback from 
> the current maintainer.
> 
> Thank you.
> 
> Luca.
> 
>> On 19 Apr 2018, at 22:48, Oleg Nenashev > wrote:
>> 
>> +1. If there is no response, let's transfer ownership once the response 
>> timeout expires
>> 
>> On Thursday, April 19, 2018 at 12:54:04 PM UTC+2, lucamilanesio wrote:
>> Sounds good, thanks for the feedback. 
>> 
>> Luca 
>> 
>> > On 19 Apr 2018, at 11:53, Daniel Beck > wrote: 
>> > 
>> > 
>> >> On 19. Apr 2018, at 09:55, Luca Milanesio > 
>> >> wrote: 
>> >> 
>> >> am I following the right process to get access to the statistics-gatherer 
>> >> plugin? 
>> >> It is over two weeks that PRs for important bug-fixes are stuck. 
>> >> 
>> >> I am really close to fork it, which could create confusion in people 
>> >> discovering it through the Plugin Manager in Jenkins. 
>> > 
>> > Hi Luca, 
>> > 
>> > You're on the right track here. We try to give maintainers adequate time 
>> > to respond, taking into account potential vacations etc., before giving 
>> > someone else access, to minimize the potential for conflict down the road. 
>> > 
>> > Daniel 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google Groups 
>> > "Jenkins Developers" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to jenkinsci-de...@googlegroups.com <>. 
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/jenkinsci-dev/484FA5D3-CBBE-4B60-B0D6-E6719233BF6C%40beckweb.net
>> >  
>> > <https://groups.google.com/d/msgid/jenkinsci-dev/484FA5D3-CBBE-4B60-B0D6-E6719233BF6C%40beckweb.net>.
>> >  
>> > For more options, visit https://groups.google.com/d/optout 
>> > <https://groups.google.com/d/optout>. 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/76f7e784-0c76-4cb1-bab2-a66c54e39ad5%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/76f7e784-0c76-4cb1-bab2-a66c54e39ad5%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/77f863e7-8ee5-40c3-a9fb-55c888197a1f%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/77f863e7-8ee5-40c3-a9fb-55c888197a1f%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4EAF165B-E834-4EC3-BF95-CC68B1653AA9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Any updates? The timeout ended yesterday and we got no further feedback from 
the current maintainer.

Thank you.

Luca.

> On 19 Apr 2018, at 22:48, Oleg Nenashev  wrote:
> 
> +1. If there is no response, let's transfer ownership once the response 
> timeout expires
> 
> On Thursday, April 19, 2018 at 12:54:04 PM UTC+2, lucamilanesio wrote:
> Sounds good, thanks for the feedback. 
> 
> Luca 
> 
> > On 19 Apr 2018, at 11:53, Daniel Beck > wrote: 
> > 
> > 
> >> On 19. Apr 2018, at 09:55, Luca Milanesio > wrote: 
> >> 
> >> am I following the right process to get access to the statistics-gatherer 
> >> plugin? 
> >> It is over two weeks that PRs for important bug-fixes are stuck. 
> >> 
> >> I am really close to fork it, which could create confusion in people 
> >> discovering it through the Plugin Manager in Jenkins. 
> > 
> > Hi Luca, 
> > 
> > You're on the right track here. We try to give maintainers adequate time to 
> > respond, taking into account potential vacations etc., before giving 
> > someone else access, to minimize the potential for conflict down the road. 
> > 
> > Daniel 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Jenkins Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to jenkinsci-de...@googlegroups.com <>. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/jenkinsci-dev/484FA5D3-CBBE-4B60-B0D6-E6719233BF6C%40beckweb.net
> >  
> > <https://groups.google.com/d/msgid/jenkinsci-dev/484FA5D3-CBBE-4B60-B0D6-E6719233BF6C%40beckweb.net>.
> >  
> > For more options, visit https://groups.google.com/d/optout 
> > <https://groups.google.com/d/optout>. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/76f7e784-0c76-4cb1-bab2-a66c54e39ad5%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/76f7e784-0c76-4cb1-bab2-a66c54e39ad5%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4743CCCE-5660-4282-8A94-24F73FEC98A8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Sounds good, thanks for the feedback.

Luca

> On 19 Apr 2018, at 11:53, Daniel Beck  wrote:
> 
> 
>> On 19. Apr 2018, at 09:55, Luca Milanesio  wrote:
>> 
>> am I following the right process to get access to the statistics-gatherer 
>> plugin?
>> It is over two weeks that PRs for important bug-fixes are stuck.
>> 
>> I am really close to fork it, which could create confusion in people 
>> discovering it through the Plugin Manager in Jenkins.
> 
> Hi Luca,
> 
> You're on the right track here. We try to give maintainers adequate time to 
> respond, taking into account potential vacations etc., before giving someone 
> else access, to minimize the potential for conflict down the road.
> 
> Daniel
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/484FA5D3-CBBE-4B60-B0D6-E6719233BF6C%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/BC6EF91B-7E90-4FE2-9742-F44A4587659B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Hi Daniel, Oleg,
am I following the right process to get access to the statistics-gatherer 
plugin?
It is over two weeks that PRs for important bug-fixes are stuck.

I am really close to fork it, which could create confusion in people 
discovering it through the Plugin Manager in Jenkins.

Thanks for your feedback.

Luca.

> On 18 Apr 2018, at 22:56, Luca Milanesio  wrote:
> 
> Ping @Admins of the JenkinsCI org :-)
> 
>> On 18 Apr 2018, at 10:05, Luca Milanesio  wrote:
>> 
>> Any news on this request?
>> 
>> I would wait a couple of days more and if there is no movement, I'll have no 
>> choice but forking it :-(
>> I agree with Daniel, forking would create confusion. 
>> However, having a plugin that extract statistics and is up-to-date with 
>> Jenkins 2.0 and Pipelines is definitely needed.
>> 
>> Let me know if you guys have other options :-)
>> 
>> As proposal for the forked plugin name:
>> "Events Collector"
> 
> Thinking aloud, a *brand new* fork could make a lot of sense, because the 
> collection of the events should be de-coupled from the implementation of its 
> transports.
> The current structure of this plugin, instead, has the transport hardcoded in 
> it, which isn't good at all.
> 
> I added the support for LOGBack which is good, because allows to de-couple 
> the appenders' transport by just configuring it in the logback.xml.
> 
> The *brand new* fork could then called:
> "LOGBack Events Collector"
> 
> The "out-of-the-box" benefits would be huge on the varieties of transports 
> available for LOGBack:
> - storage to a DB
> - ElasticSearch
> - NATS
> - Kafka
> - pure Socket
> - ...
> 
> What do you think?
> Should I just start over?
> 
> Luca.
> 
>> 
>> Luca.
>> 
>> 
>>> On 10 Apr 2018, at 08:00, Daniel Beck  wrote:
>>> 
>>> 
>>>> On 10. Apr 2018, at 08:45, Luca Milanesio  wrote:
>>>> 
>>>> What is the wait time for getting this escalated and giving the 
>>>> possibility to fix bugs on the plugin?
>>>> Alternatively, should I just submit a brand-new plugin proposal? (which 
>>>> could cause confusion: people may not know which one is "active")
>>> 
>>> Two weeks is the typical waiting time after reaching out to maintainers 
>>> directly.
>>> 
>>> Up to you whether you create a new plugin, but like you point out, "plugin 
>>> overload" has in the past been a source for user confusion and irritation.
>>> 
>> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/66BEBEA0-2C71-4784-AB04-B66F37AB0873%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Ping @Admins of the JenkinsCI org :-)

> On 18 Apr 2018, at 10:05, Luca Milanesio  wrote:
> 
> Any news on this request?
> 
> I would wait a couple of days more and if there is no movement, I'll have no 
> choice but forking it :-(
> I agree with Daniel, forking would create confusion. 
> However, having a plugin that extract statistics and is up-to-date with 
> Jenkins 2.0 and Pipelines is definitely needed.
> 
> Let me know if you guys have other options :-)
> 
> As proposal for the forked plugin name:
> "Events Collector"

Thinking aloud, a *brand new* fork could make a lot of sense, because the 
collection of the events should be de-coupled from the implementation of its 
transports.
The current structure of this plugin, instead, has the transport hardcoded in 
it, which isn't good at all.

I added the support for LOGBack which is good, because allows to de-couple the 
appenders' transport by just configuring it in the logback.xml.

The *brand new* fork could then called:
"LOGBack Events Collector"

The "out-of-the-box" benefits would be huge on the varieties of transports 
available for LOGBack:
- storage to a DB
- ElasticSearch
- NATS
- Kafka
- pure Socket
- ...

What do you think?
Should I just start over?

Luca.

> 
> Luca.
> 
> 
>> On 10 Apr 2018, at 08:00, Daniel Beck  wrote:
>> 
>> 
>>> On 10. Apr 2018, at 08:45, Luca Milanesio  wrote:
>>> 
>>> What is the wait time for getting this escalated and giving the possibility 
>>> to fix bugs on the plugin?
>>> Alternatively, should I just submit a brand-new plugin proposal? (which 
>>> could cause confusion: people may not know which one is "active")
>> 
>> Two weeks is the typical waiting time after reaching out to maintainers 
>> directly.
>> 
>> Up to you whether you create a new plugin, but like you point out, "plugin 
>> overload" has in the past been a source for user confusion and irritation.
>> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/90CED165-C7FD-4E1C-A245-B5B2176639A9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Any news on this request?

I would wait a couple of days more and if there is no movement, I'll have no 
choice but forking it :-(
I agree with Daniel, forking would create confusion. 
However, having a plugin that extract statistics and is up-to-date with Jenkins 
2.0 and Pipelines is definitely needed.

Let me know if you guys have other options :-)

As proposal for the forked plugin name:
"Events Collector"

Luca.


> On 10 Apr 2018, at 08:00, Daniel Beck  wrote:
> 
> 
>> On 10. Apr 2018, at 08:45, Luca Milanesio  wrote:
>> 
>> What is the wait time for getting this escalated and giving the possibility 
>> to fix bugs on the plugin?
>> Alternatively, should I just submit a brand-new plugin proposal? (which 
>> could cause confusion: people may not know which one is "active")
> 
> Two weeks is the typical waiting time after reaching out to maintainers 
> directly.
> 
> Up to you whether you create a new plugin, but like you point out, "plugin 
> overload" has in the past been a source for user confusion and irritation.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/255EA1E1-A1C9-4C53-9C39-72110BE4291A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Hi all,
the PR has been waiting for 13 days now (see 
https://github.com/jenkinsci/statistics-gatherer-plugin/pull/4 
<https://github.com/jenkinsci/statistics-gatherer-plugin/pull/4>) and still no 
news from the current maintainer :-(

Can we process my request this week? As discussed, I would rather avoid forking 
the plugin and create confusion. However, we need to get this done and get the 
SCM Info fixed.

Thank you in advance.
Luca.

> On 13 Apr 2018, at 10:37, Luca Milanesio  wrote:
> 
> PIng ... any news from the current Maintainers?
> Are we set for end of next week to make a decision on this?
> 
> Luca.
> 
>> On 10 Apr 2018, at 08:07, Luca Milanesio  wrote:
>> 
>> 2 weeks sound good to me, and yes, I always avoid forks :-)
>> 
>> Luca.
>> 
>>> On 10 Apr 2018, at 08:02, Joseph P  wrote:
>>> 
>>> Usually the wait period is 2 weeks :) I would not recommend creating 
>>> another plugin.
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/8b9ce146-6cf1-4b5a-a702-108ffe540d29%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8CAA50DD-A447-4362-9570-9D6373D5E13E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

PIng ... any news from the current Maintainers?
Are we set for end of next week to make a decision on this?

Luca.

> On 10 Apr 2018, at 08:07, Luca Milanesio  wrote:
> 
> 2 weeks sound good to me, and yes, I always avoid forks :-)
> 
> Luca.
> 
>> On 10 Apr 2018, at 08:02, Joseph P  wrote:
>> 
>> Usually the wait period is 2 weeks :) I would not recommend creating another 
>> plugin.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/8b9ce146-6cf1-4b5a-a702-108ffe540d29%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/F344B6F7-7224-455F-BC60-693F0C8AC51F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

2 weeks sound good to me, and yes, I always avoid forks :-)

Luca.

> On 10 Apr 2018, at 08:02, Joseph P  wrote:
> 
> Usually the wait period is 2 weeks :) I would not recommend creating another 
> plugin.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/8b9ce146-6cf1-4b5a-a702-108ffe540d29%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8CBEDFB2-204A-4096-880A-6EA8D6B381B0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

PIng ... any feedback from the current maintainer?

What is the wait time for getting this escalated and giving the possibility to 
fix bugs on the plugin?
Alternatively, should I just submit a brand-new plugin proposal? (which could 
cause confusion: people may not know which one is "active")

Thanks for the feedback.

Luca.

> On 9 Apr 2018, at 11:07, Luca Milanesio  wrote:
> 
> 
> 
>> On 9 Apr 2018, at 11:01, Daniel Beck  wrote:
>> 
>> 
>>> On 9. Apr 2018, at 09:15, Luca Milanesio  wrote:
>>> 
>>> a) His e-mail is not public, not even to the members of the JenkinsCI org
>>> b) He doesn't respond to mentions in GitHub
>>> 
>>> Does anybody have a pointer or address to reach him?
>> 
>> For future reference, the way I typically do this:
>> 
>> Check https://github.com/jenkins-infra/repository-permissions-updater for 
>> authorized uploader user names.
>> If that list is empty (~ no release in 3+ years), check uploader user names 
>> of previous releases in Artifactory.
>> 
>> Then log in to Jira, 
>> https://issues.jenkins-ci.org/secure/ViewProfile.jspa?name= and append the 
>> user name(s) you found.
> 
> Yep, that the one I found as well :-)
> Let's see his feedback on the mailing list.
> 
> I found some activity in Jira a few months ago, hopefully he is still 
> following the project !
> 
> Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/1BFFA5A0-37F7-4957-B8AE-7B3C7D902F84%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

> On 9 Apr 2018, at 11:01, Daniel Beck  wrote:
> 
> 
>> On 9. Apr 2018, at 09:15, Luca Milanesio  wrote:
>> 
>> a) His e-mail is not public, not even to the members of the JenkinsCI org
>> b) He doesn't respond to mentions in GitHub
>> 
>> Does anybody have a pointer or address to reach him?
> 
> For future reference, the way I typically do this:
> 
> Check https://github.com/jenkins-infra/repository-permissions-updater for 
> authorized uploader user names.
> If that list is empty (~ no release in 3+ years), check uploader user names 
> of previous releases in Artifactory.
> 
> Then log in to Jira, 
> https://issues.jenkins-ci.org/secure/ViewProfile.jspa?name= and append the 
> user name(s) you found.

Yep, that the one I found as well :-)
Let's see his feedback on the mailing list.

I found some activity in Jira a few months ago, hopefully he is still following 
the project !

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/74624F63-24F8-4766-9727-BB97E169BCED%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

I may have found Maxime Charron e-mail from a Jira search 
(maxime.charro...@ulaval.ca <mailto:maxime.charro...@ulaval.ca>)

@Maxime are you still maintaining the statistics-gatherer-plugin? Do you need 
any help?

Luca.

> On 9 Apr 2018, at 08:15, Luca Milanesio  wrote:
> 
> Hi all,
> I have been trying to get in touch with the maintainer of the 
> statistics-gatherer-plugin (https://github.com/maximecharron 
> <https://github.com/maximecharron>), however:
> 
> a) His e-mail is not public, not even to the members of the JenkinsCI org
> b) He doesn't respond to mentions in GitHub
> 
> Does anybody have a pointer or address to reach him?
> 
> Should we not be able to get in touch with him anymore, and the plugin has 
> been quite inactive for the past 12 months, can I ask the permission to 
> maintain the plugin?
> 
> Thank you in advance.
> 
> Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/FC4C666F-CCEC-444C-AC64-8B0ECFA64C4D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Request to become maintainer of the statistics-gatherer-plugin

[Luca Milanesio]

Hi all,
I have been trying to get in touch with the maintainer of the 
statistics-gatherer-plugin (https://github.com/maximecharron 
), however:

a) His e-mail is not public, not even to the members of the JenkinsCI org
b) He doesn't respond to mentions in GitHub

Does anybody have a pointer or address to reach him?

Should we not be able to get in touch with him anymore, and the plugin has been 
quite inactive for the past 12 months, can I ask the permission to maintain the 
plugin?

Thank you in advance.

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7C72E0FC-CE32-4982-A278-7AF7E97B397F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Events Plugin

[Luca Milanesio]

Hi Martin,
thank you for sharing the plugin with the community :-)

I am including the Jenkins Dev community as well, because this plugin could be 
really useful when used in conjunction with the Gerrit Trigger Plugin.

Luca.

> On 6 Feb 2018, at 00:17, Martin Fick  wrote:
> 
> I would like to announce the availability of the new “events” plugin which 
> was merged during the October 2017 Hackathon in London (yes, announcement 
> long overdue).
> 
>  
> As the description for the plugin says here 
> 
> https://gerrit-review.googlesource.com/admin/projects/plugins/events 
>  
> 
> “The events plugin adds a stream events API which parallels the core stream 
> events API with extensions to resume events on reconnect.  Each event is 
> stored in a separate file in a traditional filesystem.  This plugin is 
> multi-master friendly when the filesystem is shared among the masters.”
> 
>  
> I demoed this plugin running with a multi-master setup during the October 
> 2017 Gerrit User Summit (also in London). You can view the talk here:
> 
> https://gitenterprise.me/2017/12/18/gerrit-user-summit-multimaster-at-qualcomm/
>  
> 
> Internally, we have been running this plugin with our version of Gerrit (2.7 
> based) in production since early this spring, and with a multi-master setup 
> since the October 2017 summit.  This plugin is a critical piece making our 
> multi-master setup seamless to users.
> 
> I hope this message might inspire others to download and try the plugin out.  
> Feeback and questions are very welcome of course!
> 
> Thanks,
> 
>  -Martin
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of Code 
> Aurora Forum, hosted by The Linux Foundation
>  
> 
> -- 
> -- 
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com 
> 
> More info at http://groups.google.com/group/repo-discuss?hl=en 
> 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/27481087-E869-4D56-9516-11F855C3483F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

> On 19 Jan 2018, at 10:29, Sorin Sbarnea  wrote:
> 
> First let me thank Luca for his work on this plugin. I started to test it, 
> raised few bugs and also working on implementing full JJB support for it.

Thanks for trying it out :-) I always appreciated early feedback.
It is still a pre-alpha, so it is not suitable yet for production ... I am 
using it anyway on a daily basis and it works for me. However, still needs a 
lot of improvements.

> 
> Regarding contributions, I think that it would be the best to follow Jenkins 
> CI workflow (github with PR) here and avoid gerrit one.

I believe in dogfooding and innovation, rather than "standards". However, I see 
your point.
It will stay on GitHub and reviews will be welcome from both GerritHub and 
GitHub sides :-)

> 
> I see two important reasons: all jenkins plugins use the same process, 
> diverging from standard is not good.

Why? The audience is "people that work with Jenkins and Gerrit" and I'd leave 
it to them to decide the best tool to do reviews.

> Second, the plugin is too new to be considered stable,

It isn't a stable release but rather a pre-alpha.

> better to use a common/tested/stable process and focus on improving the 
> plugin. 

Gerrit Code Review and GitHub are both common, tested and stable processed 
IMHO. They have been around for ~ 10 years now.
GerritHub.io <http://gerrithub.io/> was launched in 2013, 5 years ago, has 
99.99% uptime and over 25k active users.

> 
> Moving the repo under jenkinsci and enabling Jenkins ci testing would be the 
> next natural step but there is no pressure.

See: https://github.com/jenkinsci/gerrit-plugin 
<https://github.com/jenkinsci/gerrit-plugin>


> 
> Now I only hope that I will see more activity on the issue tracker and as PRs 
> being raised. I am eager to see it as reaching a stable release and I am sure 
> that there are lots of people that could help with that.

I would have to close them and re-open them on the JenkinsCI project: the 
GerritForge one was just the pre-alpha inception.

> 
> -- sorin
> 
>> On 3 Jan 2018, at 18:16, Jesse Glick > <mailto:jgl...@cloudbees.com>> wrote:
>> 
>> On Wed, Jan 3, 2018 at 10:22 AM, Luca Milanesio
>>  wrote:
>>> If you want to submit feedback to Gerrit in your pipeline, just add the 
>>> following statement in your pipeline script:
>>> 
>>> gerrit.review("Verified", 1, "It works !")
>> 
>> I would urge you to use a plain old `Step` (no `workflow-cps`
>> dependency except in `test` scope, no `GerritDSL` + `Gerrit.groovy`),
>> e.g.:
>> 
>> gerritReview status: 'Verified', vote: 1, message: 'It works!'
>> 
>> You get a simpler implementation, *Pipeline Syntax* support,
>> compatibility with Declarative Pipeline, and the chance to work
>> unmodified with possible future execution engines.
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/E3pvb0WH4Ls/unsubscribe 
>> <https://groups.google.com/d/topic/jenkinsci-dev/E3pvb0WH4Ls/unsubscribe>.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-dev+unsubscr...@googlegroups.com 
>> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%40mail.gmail.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/E4C7F294-9200-4C1A-95BF-906A99154640%40gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/E4C7F294-9200-4C1A-95BF-906A99154640%40gmail.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/242856C9-4C87-4481-9E7C-7579208D3553%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[luca . milanesio]

Sent from my iPhone

> On 11 Jan 2018, at 02:18, David Pursehouse  wrote:
> 
>> On Thursday, January 4, 2018 at 12:22:57 AM UTC+9, lucamilanesio wrote:
>> Hi all, 
>> the wait is finally over ... and the first Alpha release of the new Gerrit 
>> Code Review plugin for Jenkins is finally available! 
>> 
>> I have submitted the request to get this hosted by the JenkinsCI 
>> organization and plugin central distribution ... however, in the meantime, 
>> you can download and install it from the GitHub repo at: 
>> https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0 
> 
> Aside from binary distribution, how do you intend to manage code reviews?  
> Will you keep it on GitHub and use pull requests, or are you going to host it 
> on gerrit-review.googlesource.com?

This is actually a good idea, however we’ll have the problem of people 
expecting to raise PRs on the GitHub Jenkinsci organisation.

GerritHub would then be a better choice, because it allows to accept PRs as 
well, and review them through Gerrit.

Luca

> 
>> 
> 
> -- 
> -- 
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/B7D5411D-1F61-4BBF-BC02-DB8BA8324E3F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Good point: let me try to see what's the effort for the declarative pipeline 
compatibility :-)

Luca.

> On 3 Jan 2018, at 18:16, Jesse Glick  wrote:
> 
> On Wed, Jan 3, 2018 at 10:22 AM, Luca Milanesio
>  wrote:
>> If you want to submit feedback to Gerrit in your pipeline, just add the 
>> following statement in your pipeline script:
>> 
>> gerrit.review("Verified", 1, "It works !")
> 
> I would urge you to use a plain old `Step` (no `workflow-cps`
> dependency except in `test` scope, no `GerritDSL` + `Gerrit.groovy`),
> e.g.:
> 
> gerritReview status: 'Verified', vote: 1, message: 'It works!'
> 
> You get a simpler implementation, *Pipeline Syntax* support,
> compatibility with Declarative Pipeline, and the chance to work
> unmodified with possible future execution engines.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6DF6680C-ACE2-4C7D-A8D0-364CCB0AC080%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi all,
the wait is finally over ... and the first Alpha release of the new Gerrit Code 
Review plugin for Jenkins is finally available!

I have submitted the request to get this hosted by the JenkinsCI organization 
and plugin central distribution ... however, in the meantime, you can download 
and install it from the GitHub repo at:
https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0

How to use it ... so, it is embarrassing simple!

1. Create a new multi-branch pipeline project
2. Select "Gerrit" as repository source
3. Add the Git/HTTP URL of your Gerrit repository (Git/SSH should work, but it 
won't allow submitting feedback to Gerrit yet)

... and there you go :-)

If you want to submit feedback to Gerrit in your pipeline, just add the 
following statement in your pipeline script:

gerrit.review("Verified", 1, "It works !")
(when it works)

OR

gerrit.review("Verified", -1, "Breaks the build ;-(")
(when it breaks)

*DISCLAIMER* this is an Alpha pre-release that is mainly focussed on getting 
early feedback on what are the most critical features to get implemented.

*Happy EARLY ADOPTION* to everyone, and thanks for your patience!

Luca.

> On 13 Dec 2017, at 07:03, Max Kovgan  wrote:
> 
> hi, Luca!
> Add me to your 'early adopters'.
> 
> M.
> 
> 
> On Tuesday, December 12, 2017 at 12:55:45 PM UTC+2, lucamilanesio wrote:
> Hi Sorin,
> I am aware that the new plugin is going to save a lot of time to a lot of 
> people :-)
> 
> Happy to see supporters and early adopters, and you'll definitely invited to 
> be one of them.
> 
> Luca.
> 
>> On 12 Dec 2017, at 10:17, Sorin Ionuț Sbârnea  wrote:
>> 
>> Hi Luca,
>> 
>> Your work on making Gerrit work with multibranch pipelines is of critical 
>> importance and I think it would be wise to share code even if you are going 
>> to rewrite it from scratch in the end. Sharing code is also a good risk 
>> mitigation as if something bad happens to you, at least someone else could 
>> continue the work instead of starting from scratch.
>> 
>> I am more than willing to sacrifice most of my winter vacation time in order 
>> to make it work, just because this could be the kind of feature that would 
>> have a huge impact at my work. Imagine 1200 jobs defined on a single jenkins 
>> instance, their number could be cut by 85% if this would work  (~7x 
>> duplication factor just because of maintenance branches).
>> 
>> Or maybe some beer could help with motivation?
>> 
>> On Monday, December 4, 2017 at 11:53:08 AM UTC, lucamilanesio wrote:
>> Apologies, as you may see by my delay in answering, I am very behind my 
>> scheduled backlog.
>> I have received useful feedback during the past Jenkins User Summit and I am 
>> working in fixing the code base in that direction.
>> 
>> I wouldn't like to share it before the refactoring, otherwise I may break 
>> compatibility :-(
>> 
>> Bear with me :-)
>> 
>> Luca.
>> 
>>> On 30 Nov 2017, at 16:17, Paolo Brocco  wrote:
>>> 
>>> Hi Luca,
>>> 
>>> you announced this in September, I was wondering if in the meantime you 
>>> could publish something? I'd be happy to test your plugin, since at work we 
>>> actually need it...
>>> 
>>> thanks for letting me know the status of your work, and if you have 
>>> something to test,
>>> 
>>> cheers, Paolo
>>> 
>>> On Friday, September 8, 2017 at 12:00:50 AM UTC+2, lucamilanesio wrote:
>>> 
>>>> On 7 Sep 2017, at 14:48, Vacelet, Manuel  wrote:
>>>> 
>>>> Hi Luca (congrats to the new gerrit maintainer BTW),
>>>> 
>>>> It does answer the question but raise a new one ;)
>>>> Have you an ETA in mind for all this ?
>>> 
>>> We are talking about weeks for sure, as I want to ship something fully 
>>> documented and working.
>>> 
>>> I was planning to share it as "showcase" with a Docker compose containing:
>>> - Gerrit 2.15 (or a pre-release)
>>> - Jenkins 2.x with BlueOcean
>>> 
>>> I believe the coupling of BlueOcean + PolyGerrit will give the "business 
>>> case" for many people to start adopting the two tools instead of heading to 
>>> GitLab or similar.
>>> 
>>> Luca.
>>> 
>>>> 
>>>> Manuel
>>>>  
>>>> 
>>>> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio  
>>>> wrote:
>>>> Hi Manuel,
>>>> I discussed the topic with Robert at th

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi Sorin,
I am aware that the new plugin is going to save a lot of time to a lot of 
people :-)

Happy to see supporters and early adopters, and you'll definitely invited to be 
one of them.

Luca.

> On 12 Dec 2017, at 10:17, Sorin Ionuț Sbârnea  wrote:
> 
> Hi Luca,
> 
> Your work on making Gerrit work with multibranch pipelines is of critical 
> importance and I think it would be wise to share code even if you are going 
> to rewrite it from scratch in the end. Sharing code is also a good risk 
> mitigation as if something bad happens to you, at least someone else could 
> continue the work instead of starting from scratch.
> 
> I am more than willing to sacrifice most of my winter vacation time in order 
> to make it work, just because this could be the kind of feature that would 
> have a huge impact at my work. Imagine 1200 jobs defined on a single jenkins 
> instance, their number could be cut by 85% if this would work  (~7x 
> duplication factor just because of maintenance branches).
> 
> Or maybe some beer could help with motivation?
> 
> On Monday, December 4, 2017 at 11:53:08 AM UTC, lucamilanesio wrote:
> Apologies, as you may see by my delay in answering, I am very behind my 
> scheduled backlog.
> I have received useful feedback during the past Jenkins User Summit and I am 
> working in fixing the code base in that direction.
> 
> I wouldn't like to share it before the refactoring, otherwise I may break 
> compatibility :-(
> 
> Bear with me :-)
> 
> Luca.
> 
>> On 30 Nov 2017, at 16:17, Paolo Brocco > wrote:
>> 
>> Hi Luca,
>> 
>> you announced this in September, I was wondering if in the meantime you 
>> could publish something? I'd be happy to test your plugin, since at work we 
>> actually need it...
>> 
>> thanks for letting me know the status of your work, and if you have 
>> something to test,
>> 
>> cheers, Paolo
>> 
>> On Friday, September 8, 2017 at 12:00:50 AM UTC+2, lucamilanesio wrote:
>> 
>>> On 7 Sep 2017, at 14:48, Vacelet, Manuel > wrote:
>>> 
>>> Hi Luca (congrats to the new gerrit maintainer BTW),
>>> 
>>> It does answer the question but raise a new one ;)
>>> Have you an ETA in mind for all this ?
>> 
>> We are talking about weeks for sure, as I want to ship something fully 
>> documented and working.
>> 
>> I was planning to share it as "showcase" with a Docker compose containing:
>> - Gerrit 2.15 (or a pre-release)
>> - Jenkins 2.x with BlueOcean
>> 
>> I believe the coupling of BlueOcean + PolyGerrit will give the "business 
>> case" for many people to start adopting the two tools instead of heading to 
>> GitLab or similar.
>> 
>> Luca.
>> 
>>> 
>>> Manuel
>>>  
>>> 
>>> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio > 
>>> wrote:
>>> Hi Manuel,
>>> I discussed the topic with Robert at the Jenkins World conference last 
>>> week, and we agreed that:
>>> 
>>> 1. More work is needed on the branch discovery side: I need to flag the 
>>> ones coming from Gerrit Changes with a specific label
>>> 2. The plugin is going to be focused on the branch source API feature: 
>>> Gerrit-branch-source similarly to GitHub-branch-source
>>> 3. Gerrit Trigger plugin will stay anyway for his specific use-case: 
>>> triggering the build based on a Gerrit stream event
>>> 
>>> Does that answer your questions?
>>> 
>>> Luca.
>>> 
>>>> On 7 Sep 2017, at 08:08, Vacelet, Manuel > wrote:
>>>> 
>>>> Hi Luca,
>>>> 
>>>> Jenkins World Conference is over, did you manage to showcase this new 
>>>> plugin ?
>>>> What's the status and what are the plans for the future ?
>>>> 
>>>> Manuel
>>>> 
>>>> On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio > 
>>>> wrote:
>>>> Hi Gerrit and Jenkins Community,
>>>> after over two years of iterations and improvements of the Gerrit CI 
>>>> workflow (https://gerrit-ci.gerritforge.com 
>>>> <https://gerrit-ci.gerritforge.com/>), I have decided that is about time 
>>>> to extract the logic of our workflow and make it available as a brand-new 
>>>> Jenkins plugin!
>>>> 
>>>> Why?
>>>> I wanted to use the Gerrit CI validation workflow with potentially any 
>>>> project, including Gerrit plugins or anybody else wanting to adopt it.
>>>&

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Apologies, as you may see by my delay in answering, I am very behind my 
scheduled backlog.
I have received useful feedback during the past Jenkins User Summit and I am 
working in fixing the code base in that direction.

I wouldn't like to share it before the refactoring, otherwise I may break 
compatibility :-(

Bear with me :-)

Luca.

> On 30 Nov 2017, at 16:17, Paolo Brocco  wrote:
> 
> Hi Luca,
> 
> you announced this in September, I was wondering if in the meantime you could 
> publish something? I'd be happy to test your plugin, since at work we 
> actually need it...
> 
> thanks for letting me know the status of your work, and if you have something 
> to test,
> 
> cheers, Paolo
> 
> On Friday, September 8, 2017 at 12:00:50 AM UTC+2, lucamilanesio wrote:
> 
>> On 7 Sep 2017, at 14:48, Vacelet, Manuel > wrote:
>> 
>> Hi Luca (congrats to the new gerrit maintainer BTW),
>> 
>> It does answer the question but raise a new one ;)
>> Have you an ETA in mind for all this ?
> 
> We are talking about weeks for sure, as I want to ship something fully 
> documented and working.
> 
> I was planning to share it as "showcase" with a Docker compose containing:
> - Gerrit 2.15 (or a pre-release)
> - Jenkins 2.x with BlueOcean
> 
> I believe the coupling of BlueOcean + PolyGerrit will give the "business 
> case" for many people to start adopting the two tools instead of heading to 
> GitLab or similar.
> 
> Luca.
> 
>> 
>> Manuel
>>  
>> 
>> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio > 
>> wrote:
>> Hi Manuel,
>> I discussed the topic with Robert at the Jenkins World conference last week, 
>> and we agreed that:
>> 
>> 1. More work is needed on the branch discovery side: I need to flag the ones 
>> coming from Gerrit Changes with a specific label
>> 2. The plugin is going to be focused on the branch source API feature: 
>> Gerrit-branch-source similarly to GitHub-branch-source
>> 3. Gerrit Trigger plugin will stay anyway for his specific use-case: 
>> triggering the build based on a Gerrit stream event
>> 
>> Does that answer your questions?
>> 
>> Luca.
>> 
>>> On 7 Sep 2017, at 08:08, Vacelet, Manuel > wrote:
>>> 
>>> Hi Luca,
>>> 
>>> Jenkins World Conference is over, did you manage to showcase this new 
>>> plugin ?
>>> What's the status and what are the plans for the future ?
>>> 
>>> Manuel
>>> 
>>> On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio > 
>>> wrote:
>>> Hi Gerrit and Jenkins Community,
>>> after over two years of iterations and improvements of the Gerrit CI 
>>> workflow (https://gerrit-ci.gerritforge.com 
>>> <https://gerrit-ci.gerritforge.com/>), I have decided that is about time to 
>>> extract the logic of our workflow and make it available as a brand-new 
>>> Jenkins plugin!
>>> 
>>> Why?
>>> I wanted to use the Gerrit CI validation workflow with potentially any 
>>> project, including Gerrit plugins or anybody else wanting to adopt it.
>>> I could just "copy & paste" our Groovy workflow, however, that does not 
>>> seem a sensible and long-term approach.
>>> I wanted to have "something more" than a pure triggering mechanism: I 
>>> wanted to extend the power of Jenkisfile with the Gerrit review workflow 
>>> verbs.
>>> 
>>> Why not?
>>> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
>>> Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger 
>>> <https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger>) enough?
>>> We couldn't use it against gerrit-review.googlesource.com 
>>> <http://gerrit-review.googlesource.com/> because stream events are just not 
>>> accessible.
>>> 
>>> There are unresolved issues about:
>>> - Stability: stream-events are based on SSH, which isn't scalable, reliable 
>>> against downtime, etc.
>>> - Usability: at every JenkinsWorld conference people still come to me 
>>> asking "how do I setup correct the Gerrit Trigger plugin"?
>>> - Integration: using it inside a JenkinsFile isn't that straightforward and 
>>> multi-branch projects aren't supported either
>>> 
>>> What would it be?
>>> I will publish a new plugin named "Gerrit Pipeline Plugin."
>>> The new name indicates:
>>> - Deep integration with Jenkins Pipeline
>>

[Announce] Video available on how we use Jenkins + Logstash plugin for the Gerrit CI pipeline

[Luca Milanesio]

Hi, both Jenkins and Gerrit Community.

we have just published the YouTube + transcript of the "Jenkins forever" 
presentation at the Gerrit User Summit 2017 in London:
https://gitenterprise.me/2017/10/24/gerrit-user-summit-jenkins-forever/

Hopefully, it could be an inspiration for all of those who need to keep a very 
long history of build logs in Jenkins (like us from the Gerrit Code Review 
OpenSource project) and for those Jenkins Developers that are currently 
implementing the "long-term pluggable storage" for Jenkins build logs.

As mentioned multiple times at the JenkinsWorld conferences, keeping logs in 
Jenkins is a real pain :-(
- Slow down the Jenkins master response time
- Overload the underlying filesystem

Build logs are, however, a handy and precious source of information: removing 
them doesn't seem a viable solution for most of us.

The solution we implemented at the Gerrit Code Review CI pipeline solves both 
problems, by leveraging Apache Spark and Google Cloud Storage.
>From a user's perspective, it is all transparent; it allows to honor the 
>backlinks from the Gerrit Changes back to the Jenkins CI URL transparently.

Happy watching of the video or, if you prefer to read, the reading of the talk 
transcript on my blog.

Feedback and comments are more than welcome :-)

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/93895072-02A0-4131-B5B7-A666A9ED3E2E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

> On 7 Sep 2017, at 14:48, Vacelet, Manuel  wrote:
> 
> Hi Luca (congrats to the new gerrit maintainer BTW),
> 
> It does answer the question but raise a new one ;)
> Have you an ETA in mind for all this ?

We are talking about weeks for sure, as I want to ship something fully 
documented and working.

I was planning to share it as "showcase" with a Docker compose containing:
- Gerrit 2.15 (or a pre-release)
- Jenkins 2.x with BlueOcean

I believe the coupling of BlueOcean + PolyGerrit will give the "business case" 
for many people to start adopting the two tools instead of heading to GitLab or 
similar.

Luca.

> 
> Manuel
>  
> 
> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio  <mailto:luca.milane...@gmail.com>> wrote:
> Hi Manuel,
> I discussed the topic with Robert at the Jenkins World conference last week, 
> and we agreed that:
> 
> 1. More work is needed on the branch discovery side: I need to flag the ones 
> coming from Gerrit Changes with a specific label
> 2. The plugin is going to be focused on the branch source API feature: 
> Gerrit-branch-source similarly to GitHub-branch-source
> 3. Gerrit Trigger plugin will stay anyway for his specific use-case: 
> triggering the build based on a Gerrit stream event
> 
> Does that answer your questions?
> 
> Luca.
> 
>> On 7 Sep 2017, at 08:08, Vacelet, Manuel > <mailto:manuel.vace...@enalean.com>> wrote:
>> 
>> Hi Luca,
>> 
>> Jenkins World Conference is over, did you manage to showcase this new plugin 
>> ?
>> What's the status and what are the plans for the future ?
>> 
>> Manuel
>> 
>> On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio > <mailto:luca.milane...@gmail.com>> wrote:
>> Hi Gerrit and Jenkins Community,
>> after over two years of iterations and improvements of the Gerrit CI 
>> workflow (https://gerrit-ci.gerritforge.com 
>> <https://gerrit-ci.gerritforge.com/>), I have decided that is about time to 
>> extract the logic of our workflow and make it available as a brand-new 
>> Jenkins plugin!
>> 
>> Why?
>> I wanted to use the Gerrit CI validation workflow with potentially any 
>> project, including Gerrit plugins or anybody else wanting to adopt it.
>> I could just "copy & paste" our Groovy workflow, however, that does not seem 
>> a sensible and long-term approach.
>> I wanted to have "something more" than a pure triggering mechanism: I wanted 
>> to extend the power of Jenkisfile with the Gerrit review workflow verbs.
>> 
>> Why not?
>> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
>> Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger 
>> <https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger>) enough?
>> We couldn't use it against gerrit-review.googlesource.com 
>> <http://gerrit-review.googlesource.com/> because stream events are just not 
>> accessible.
>> 
>> There are unresolved issues about:
>> - Stability: stream-events are based on SSH, which isn't scalable, reliable 
>> against downtime, etc.
>> - Usability: at every JenkinsWorld conference people still come to me asking 
>> "how do I setup correct the Gerrit Trigger plugin"?
>> - Integration: using it inside a JenkinsFile isn't that straightforward and 
>> multi-branch projects aren't supported either
>> 
>> What would it be?
>> I will publish a new plugin named "Gerrit Pipeline Plugin."
>> The new name indicates:
>> - Deep integration with Jenkins Pipeline
>> - Out-of-the-box integration with Gerrit validation workflow in the pipeline
>> 
>> A simple example scripted Jenkinsfile would be:
>> 
>> node {
>> checkout scm
>> 
>> gerrit.withServer("http://gerrit:8080/ <http://gerrit:8080/>", "gerrit") 
>> {
>> 
>> try {
>> docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
>> stage('Build') {
>> sh 'sbt compile'
>> }
>> stage('Test') {
>> sh 'sbt 'test'
>> }
>> }
>> 
>> gerrit.review("Verified", 1, "It works !")
>> } catch (e) {
>> gerrit.review("Verified", -1, "Breaks the build ;-(")
>> throw e
>> }
>> }
>> }
>> 
>> (Where:
>> - https://gerrit-rev

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi Manuel,
I discussed the topic with Robert at the Jenkins World conference last week, 
and we agreed that:

1. More work is needed on the branch discovery side: I need to flag the ones 
coming from Gerrit Changes with a specific label
2. The plugin is going to be focused on the branch source API feature: 
Gerrit-branch-source similarly to GitHub-branch-source
3. Gerrit Trigger plugin will stay anyway for his specific use-case: triggering 
the build based on a Gerrit stream event

Does that answer your questions?

Luca.

> On 7 Sep 2017, at 08:08, Vacelet, Manuel  wrote:
> 
> Hi Luca,
> 
> Jenkins World Conference is over, did you manage to showcase this new plugin ?
> What's the status and what are the plans for the future ?
> 
> Manuel
> 
> On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio  <mailto:luca.milane...@gmail.com>> wrote:
> Hi Gerrit and Jenkins Community,
> after over two years of iterations and improvements of the Gerrit CI workflow 
> (https://gerrit-ci.gerritforge.com <https://gerrit-ci.gerritforge.com/>), I 
> have decided that is about time to extract the logic of our workflow and make 
> it available as a brand-new Jenkins plugin!
> 
> Why?
> I wanted to use the Gerrit CI validation workflow with potentially any 
> project, including Gerrit plugins or anybody else wanting to adopt it.
> I could just "copy & paste" our Groovy workflow, however, that does not seem 
> a sensible and long-term approach.
> I wanted to have "something more" than a pure triggering mechanism: I wanted 
> to extend the power of Jenkisfile with the Gerrit review workflow verbs.
> 
> Why not?
> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
> Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger 
> <https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger>) enough?
> We couldn't use it against gerrit-review.googlesource.com 
> <http://gerrit-review.googlesource.com/> because stream events are just not 
> accessible.
> 
> There are unresolved issues about:
> - Stability: stream-events are based on SSH, which isn't scalable, reliable 
> against downtime, etc.
> - Usability: at every JenkinsWorld conference people still come to me asking 
> "how do I setup correct the Gerrit Trigger plugin"?
> - Integration: using it inside a JenkinsFile isn't that straightforward and 
> multi-branch projects aren't supported either
> 
> What would it be?
> I will publish a new plugin named "Gerrit Pipeline Plugin."
> The new name indicates:
> - Deep integration with Jenkins Pipeline
> - Out-of-the-box integration with Gerrit validation workflow in the pipeline
> 
> A simple example scripted Jenkinsfile would be:
> 
> node {
> checkout scm
> 
> gerrit.withServer("http://gerrit:8080/ <http://gerrit:8080/>", "gerrit") {
> 
> try {
> docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
> stage('Build') {
> sh 'sbt compile'
> }
> stage('Test') {
> sh 'sbt 'test'
> }
> }
> 
> gerrit.review("Verified", 1, "It works !")
> } catch (e) {
> gerrit.review("Verified", -1, "Breaks the build ;-(")
> throw e
> }
> }
> }
> 
> (Where:
> - https://gerrit-review.example.com <https://gerrit-review.example.com/> 
> would be the Gerrit URL
> - mycredentialsid would be the id of the credentials to access Gerrit)
> 
> One key-aspect will be: stateless, configuration-less (apart from the 
> credentials stored in Jenkins keychain)
> That means that multiple Jobs, multiple branches of the same Job, can have 
> their own Gerrit integration defined and working out-of-the-box.
> 
> No more people asking "how do I configure the Gerrit integration"?
> You'll just define a gerrit.withServer() { } and ... it will just work.
> 
> When?
> I am planning to showcase the first prototype of the new plugin at the 
> Jenkins World Conference in San Francisco inside my "Data-Driven Pipeline 
> workshop."
> (https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free
>  
> <https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free>)
> Shortly afterward, I will publish the plugin on the GerritForge's GitHub 
> account and will start the integration process into the Jenkins CI 
> organization.
> 
> Next steps?
> A second iteration of the plugi

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hey Jesse,
that's absolutely fantastic feedback :-)

I believe we can close Phase #2 and #3 and have it finalised and announced 
officially at the Jenkins World Summit in SFO !!

> On 18 Aug 2017, at 17:04, Jesse Glick  wrote:
> 
> On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio
>  wrote:
>> Would you have time at Jenkins World 2017 to pop up at the GerritForge booth 
>> and have a face-to-face chat on the plugins' evolutions?
> 
> Absolutely! Grab me if I forget to come by.

Will do.

> 
>> The goal of this plugin is allow a Jenkinsfile developer *without any 
>> permissions* on the Jenkins configuration to integrate with a remote Gerrit 
>> server.
>> You can do it with the Declarative Pipeline as well in the scm section.
> 
> For a non-multibranch project, you mean—fine, that would be a good use
> for a custom `Step`.

I will be using in my workshop for multi-branch project as well, exactly 
because the *entire* configuration can stay inside the Jenkinsfile.
In large organisations there is a lot control and politics in the management of 
the global settings: having something that works nicely and is in control of 
the developer is *way better* than going through bureaucracy at times.

But the answer is: "it depends" :-)

> 
>> In our Gerrit CI scenario we include as well the reason of the failure as 
>> "companion message".
>> Example: you failed the correct formatting check of three files => we 
>> include the name of the files in the review message.
> 
> You could look for `ErrorAction` on the `FlowEndNode`, in case the
> build ended in an exception. That would handle many common cases.

BUT you may want to send feedback to Gerrit *during* the build flow as well.

Example of pipeline: steps => action on Gerrit
- scm checkout
- code style check => CodeStyle +1 / -1 to Gerrit
- build
- test (backend) => Backend Verified +1
- test (frontend) => Frontend Verified +1
- libraries compliance check => Library Compliance +1
- archive
- deploy
- integration test => Integration +1
- SUCCESS => Verified +1

As the entire pipeline could last even 20' or more ... it is *very valuable* to 
the developer to have feedback *as soon as possible* even if the build isn't 
complete.

> 
> More broadly, perhaps the `build-failure-analyzer` plugin could offer
> an API for programmatically scraping the apparent problem from a
> build, for consumption by other plugins. Would need some design work.

Or just include the review() code inside a compensation try / catch of your 
steps.

> 
>> Another example is the name of the review label: could be different than 
>> "Verified".
>> We have in Gerrit CI:
>> - Verified
>> - PolyGerrit Verified
>> - Library Compliance
>> - Codestyle
> 
> Sure, this is what I meant by “advanced customization”.

Most of Gerrit users are sort of "advanced" :-)
The small teams are more likely to use GitHub or GitLab ... whilst Gerrit 
projects are typically composed by hundreds of people with complex requirements.

> 
>> GitHub, GitLab and BitBucket are "lightweight" code reviews> where possibly 
>> the defaults are good for everyone
> 
> Actually plenty of people request all sorts of customizations for
> GitHub behavior.

:-)

> 
>> it is possible to list the projects using Gerrit REST API and auto-configure 
>> the jobs with a Jenkinsfile inside.
>> It would be actually really cool to show the "out-of-the-box" integration 
>> between Gerrit and Jenkins :-)
> 
> Exactly.
> 
> · Start Jenkins, finish setup wizard.
> · Click New Item, select “Gerrit Organization”.
> · Enter server URL where prompted, and admin credentials.
> · Start adding `Jenkinsfile`s in patches and relax.

That would be *super awesome*. Shall we put on-lien a demo-video once that 
scenario is finalised?

> 
>> At the moment already "shows-up" in BlueOcean, so we can "technically say" 
>> it is already integrated ... but it is not :-(
>> - You don't see the "Gerrit Changes tab"
>> - You have to visibility of the Changes / Patch-sets granularity
> 
> Not sure of details but it is possible `scm-api` already defines the
> SPIs you need here. Whether Blue Ocean calls them appropriately is
> another question.

Good to know, it should then be less complicated than I have originally 
envisaged.

> 
>> - You cannot navigate back and forth to Gerrit from BlueOcean
> 
> BO → Gerrit would probably be a “web URL” defined in `scm-api`. Gerrit
> → BO should be handled by `display-url-api`.

Cool :-)

> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Dev

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi Jesse,
thanks for the feedback, that's what I needed as guidance for finalising the 
plugin.

P.S. Would you have time at Jenkins World 2017 to pop up at the GerritForge 
booth and have a face-to-face chat on the plugins' evolutions?

> On 18 Aug 2017, at 16:39, Jesse Glick  wrote:
> 
> On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio
>  wrote:
>>gerrit.withServer("http://gerrit:8080/";, "gerrit") {
> 
> I would strongly advise you *not* to use the “DSL style”
> (`workflow-cps` dependency). Define `Step`s and leave it at that.

The goal of this plugin is allow a Jenkinsfile developer *without any 
permissions* on the Jenkins configuration to integrate with a remote Gerrit 
server.
You can do it with the Declarative Pipeline as well in the scm section.

True that you *could* get that info from the SCM and not requiring any 
configuration at all: that could be a common sense default.
However, you could get the code via SSH and communicate with Gerrit REST API 
over HTTP using a different hostname.

> 
>>gerrit.review("Verified", 1, "It works !")
> 
> Why do you even need any special steps? IMO it should suffice to have
> a generic `Jenkinsfile`, and if the branch source is configured to
> post reviews, a successful build would be +1 and an unstable/failed
> build -1. This is what, say, `github-branch-source` does with the
> GitHub Status API.

In our Gerrit CI scenario we include as well the reason of the failure as 
"companion message".
Example: you failed the correct formatting check of three files => we include 
the name of the files in the review message.

Another example is the name of the review label: could be different than 
"Verified".
We have in Gerrit CI:
- Verified
- PolyGerrit Verified
- Library Compliance
- Codestyle

The logic of what to include in the message *stays* within the pipeline.
However, a common sense default could be the having a "Verified" label with +1 
and -1 ... but it is not given for granted to be fully working in all projects.

Gerrit is a *fully featured* code-review system, whilst GitHub, GitLab and 
BitBucket are "lightweight" code reviews where possibly the defaults are good 
for everyone :-)

> 
> (There could be steps added for advanced customization, like adding
> one vote per test stage or whatever, but you should be able to
> integrate with voting without making any mention of Gerrit in your
> `Jenkinsfile`.)

Yes, with some common-sense defaults.

> 
> BTW did you implement `SCMNavigator`? I am not a Gerrit user but my
> understanding was that it should be possible to query the server for
> hosted repositories and set up jobs with `Jenkinsfile`s automatically,
> making it that much easier to get started in a big organization.

Not yet, but yes it is possible to list the projects using Gerrit REST API and 
auto-configure the jobs with a Jenkinsfile inside.
It would be actually really cool to show the "out-of-the-box" integration 
between Gerrit and Jenkins :-)

> 
>> A second iteration of the plugin would have a Declarative pipeline
>> equivalent as well, which would require even less code required.
> 
> See above—if there is nothing mandatory in the `Jenkinsfile`, there is
> no need to do anything special for Declarative.
> 
> And note that DSL-style integrations will not work in Declarative.
> Only plain steps.

I know, I started with the DSL-style because is the most similar to what we 
have in gerrit-ci.gerritforge.com.
Next iteration will be towards a more Declarative-style pipeline as well.

> 
>> A third iteration of the plugin would support BlueOcean as well, to have a
>> fully UX-integrated experience.
> 
> I would hope that there is no special BlueOcean integration needed.
> You should only need to implement all applicable `scm-api` features,
> such as head categories.

At the moment already "shows-up" in BlueOcean, so we can "technically say" it 
is already integrated ... but it is not :-(
- You don't see the "Gerrit Changes tab"
- You have to visibility of the Changes / Patch-sets granularity
- You cannot navigate back and forth to Gerrit from BlueOcean

... that will come :-) thanks to suggestions and ideas like yours in this post 
:-)

> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0awVVQJn%2BPaJ%3DYV3g1%3DpU%2BgEwOq0kbBQp8x_xf771FfA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
Y

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

> On 18 Aug 2017, at 14:10, Robert Sandell  wrote:
> 
> Cool,
> So is this intended as a Branch API 
> <https://github.com/jenkinsci/branch-api-plugin/blob/master/docs/user.adoc> 
> implementation? Something a la GitHub Branch Source Plugin 
> <https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin>?

Yes, exactly.
That would allow to have separate Jenkinsfile definitions even on different 
Changes and Patch-Sets.

> Which is what my mind goes to when reading things like "Out-of-the-box 
> integration with Gerrit validation workflow in the pipeline".

Yep.

> From a quick reading I'm not sure that is what you are planning, it seems 
> like something else?

Nope, that's exactly my goal.

> 
> The gerrit-branch-source-plugin is something that has been on my todo list 
> for over two years and I haven't been able to free enough cycles to implement 
> it yet. So getting that ghost off my chest would be nice ;)

Yes, I remember we talked about that during the last Jenkins World Summit in 
2016, lots of people wanted that and came to our Booth asking if we did 
something in that direction.
This year, we'll have some answers for them :-)

Looking forward to get your reviews ;-)

Luca.

> 
> /B
> 
> 2017-08-18 13:44 GMT+02:00 Luca Milanesio  <mailto:luca.milane...@gmail.com>>:
> 
>> On 18 Aug 2017, at 12:19, Gustaf Lundh > <mailto:gustaf.lu...@axis.com>> wrote:
>> 
>> Cool stuff! Really looking forward to try it out!
>> 
>> > - Stability: stream-events are based on SSH, which isn't scalable, 
>> > reliable against downtime, etc.
>> 
>> Please note: The Gerrit Trigger plugin does support consuming events from 
>> rabbit-mq and also from the Gerrit event-log plugin.
> 
> Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a 
> lot* of extra complexity and infrastructure :-(
> Additionally, event-log plugin stores all the events on the Gerrit DB, which 
> is *again* a lot of extra overhead :-((
> 
>> 
>> I think it is also worth nothing that Gerrit Trigger is push based and not 
>> pull based. Which makes quite a difference when you have a great amount of 
>> projects.
> 
> My new plugin is push based as well, based on WebHooks.
> But I agree with you, for a very large large scale setup, the Gerrit Trigger 
> Plugin remains the 1st choice and the extra overhead of infrastructure is 
> justified by the size of the installation.
> For medium-small scale setups, it is way too complex for the people to setup 
> and manage, based from the feedback I got from my clients :-(
> 
>> 
>> /Gustaf
>> 
>> 
>> On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio wrote:
>> Hi Gerrit and Jenkins Community,
>> after over two years of iterations and improvements of the Gerrit CI 
>> workflow (https://gerrit-ci.gerritforge.com 
>> <https://gerrit-ci.gerritforge.com/>), I have decided that is about time to 
>> extract the logic of our workflow and make it available as a brand-new 
>> Jenkins plugin!
>> 
>> Why?
>> I wanted to use the Gerrit CI validation workflow with potentially any 
>> project, including Gerrit plugins or anybody else wanting to adopt it.
>> I could just "copy & paste" our Groovy workflow, however, that does not seem 
>> a sensible and long-term approach.
>> I wanted to have "something more" than a pure triggering mechanism: I wanted 
>> to extend the power of Jenkisfile with the Gerrit review workflow verbs.
>> 
>> Why not?
>> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
>> Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger 
>> <https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger>) enough?
>> We couldn't use it against gerrit-review.googlesource.com 
>> <http://gerrit-review.googlesource.com/> because stream events are just not 
>> accessible.
>> 
>> There are unresolved issues about:
>> - Stability: stream-events are based on SSH, which isn't scalable, reliable 
>> against downtime, etc.
>> - Usability: at every JenkinsWorld conference people still come to me asking 
>> "how do I setup correct the Gerrit Trigger plugin"?
>> - Integration: using it inside a JenkinsFile isn't that straightforward and 
>> multi-branch projects aren't supported either
>> 
>> What would it be?
>> I will publish a new plugin named "Gerrit Pipeline Plugin."
>> The new name indicates:
>> - Deep integration with Jenkins Pipeline
>> - Out-of-the-box integration 

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

> On 18 Aug 2017, at 12:19, Gustaf Lundh  wrote:
> 
> Cool stuff! Really looking forward to try it out!
> 
> > - Stability: stream-events are based on SSH, which isn't scalable, reliable 
> > against downtime, etc.
> 
> Please note: The Gerrit Trigger plugin does support consuming events from 
> rabbit-mq and also from the Gerrit event-log plugin.

Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a 
lot* of extra complexity and infrastructure :-(
Additionally, event-log plugin stores all the events on the Gerrit DB, which is 
*again* a lot of extra overhead :-((

> 
> I think it is also worth nothing that Gerrit Trigger is push based and not 
> pull based. Which makes quite a difference when you have a great amount of 
> projects.

My new plugin is push based as well, based on WebHooks.
But I agree with you, for a very large large scale setup, the Gerrit Trigger 
Plugin remains the 1st choice and the extra overhead of infrastructure is 
justified by the size of the installation.
For medium-small scale setups, it is way too complex for the people to setup 
and manage, based from the feedback I got from my clients :-(

> 
> /Gustaf
> 
> 
> On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio wrote:
> Hi Gerrit and Jenkins Community,
> after over two years of iterations and improvements of the Gerrit CI workflow 
> (https://gerrit-ci.gerritforge.com ), I 
> have decided that is about time to extract the logic of our workflow and make 
> it available as a brand-new Jenkins plugin!
> 
> Why?
> I wanted to use the Gerrit CI validation workflow with potentially any 
> project, including Gerrit plugins or anybody else wanting to adopt it.
> I could just "copy & paste" our Groovy workflow, however, that does not seem 
> a sensible and long-term approach.
> I wanted to have "something more" than a pure triggering mechanism: I wanted 
> to extend the power of Jenkisfile with the Gerrit review workflow verbs.
> 
> Why not?
> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
> Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger 
> ) enough?
> We couldn't use it against gerrit-review.googlesource.com 
>  because stream events are just not 
> accessible.
> 
> There are unresolved issues about:
> - Stability: stream-events are based on SSH, which isn't scalable, reliable 
> against downtime, etc.
> - Usability: at every JenkinsWorld conference people still come to me asking 
> "how do I setup correct the Gerrit Trigger plugin"?
> - Integration: using it inside a JenkinsFile isn't that straightforward and 
> multi-branch projects aren't supported either
> 
> What would it be?
> I will publish a new plugin named "Gerrit Pipeline Plugin."
> The new name indicates:
> - Deep integration with Jenkins Pipeline
> - Out-of-the-box integration with Gerrit validation workflow in the pipeline
> 
> A simple example scripted Jenkinsfile would be:
> 
> node {
> checkout scm
> 
> gerrit.withServer("http://gerrit:8080/ ", "gerrit") {
> 
> try {
> docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
> stage('Build') {
> sh 'sbt compile'
> }
> stage('Test') {
> sh 'sbt 'test'
> }
> }
> 
> gerrit.review("Verified", 1, "It works !")
> } catch (e) {
> gerrit.review("Verified", -1, "Breaks the build ;-(")
> throw e
> }
> }
> }
> 
> (Where:
> - https://gerrit-review.example.com  
> would be the Gerrit URL
> - mycredentialsid would be the id of the credentials to access Gerrit)
> 
> One key-aspect will be: stateless, configuration-less (apart from the 
> credentials stored in Jenkins keychain)
> That means that multiple Jobs, multiple branches of the same Job, can have 
> their own Gerrit integration defined and working out-of-the-box.
> 
> No more people asking "how do I configure the Gerrit integration"?
> You'll just define a gerrit.withServer() { } and ... it will just work.
> 
> When?
> I am planning to showcase the first prototype of the new plugin at the 
> Jenkins World Conference in San Francisco inside my "Data-Driven Pipeline 
> workshop."
> (https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free
>  
> )
> Shortly afterward, I will publish the plugin on the GerritForge's GitHub 
> account and will start the integration process into the Jenkins CI 
> organization.
> 
> Next steps?
> A second iteration of the plugin would have a Declarative pipeline equivalent 
> as well, which would require even less code required.
> A third iteration of the plugin would support B

[Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi Gerrit and Jenkins Community,
after over two years of iterations and improvements of the Gerrit CI workflow 
(https://gerrit-ci.gerritforge.com), I have decided that is about time to 
extract the logic of our workflow and make it available as a brand-new Jenkins 
plugin!

Why?
I wanted to use the Gerrit CI validation workflow with potentially any project, 
including Gerrit plugins or anybody else wanting to adopt it.
I could just "copy & paste" our Groovy workflow, however, that does not seem a 
sensible and long-term approach.
I wanted to have "something more" than a pure triggering mechanism: I wanted to 
extend the power of Jenkisfile with the Gerrit review workflow verbs.

Why not?
Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger 
Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger) enough?
We couldn't use it against gerrit-review.googlesource.com because stream events 
are just not accessible.

There are unresolved issues about:
- Stability: stream-events are based on SSH, which isn't scalable, reliable 
against downtime, etc.
- Usability: at every JenkinsWorld conference people still come to me asking 
"how do I setup correct the Gerrit Trigger plugin"?
- Integration: using it inside a JenkinsFile isn't that straightforward and 
multi-branch projects aren't supported either

What would it be?
I will publish a new plugin named "Gerrit Pipeline Plugin."
The new name indicates:
- Deep integration with Jenkins Pipeline
- Out-of-the-box integration with Gerrit validation workflow in the pipeline

A simple example scripted Jenkinsfile would be:

node {
checkout scm

gerrit.withServer("http://gerrit:8080/";, "gerrit") {

try {
docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
stage('Build') {
sh 'sbt compile'
}
stage('Test') {
sh 'sbt 'test'
}
}

gerrit.review("Verified", 1, "It works !")
} catch (e) {
gerrit.review("Verified", -1, "Breaks the build ;-(")
throw e
}
}
}

(Where:
- https://gerrit-review.example.com would be the Gerrit URL
- mycredentialsid would be the id of the credentials to access Gerrit)

One key-aspect will be: stateless, configuration-less (apart from the 
credentials stored in Jenkins keychain)
That means that multiple Jobs, multiple branches of the same Job, can have 
their own Gerrit integration defined and working out-of-the-box.

No more people asking "how do I configure the Gerrit integration"?
You'll just define a gerrit.withServer() { } and ... it will just work.

When?
I am planning to showcase the first prototype of the new plugin at the Jenkins 
World Conference in San Francisco inside my "Data-Driven Pipeline workshop."
(https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free
 
)
Shortly afterward, I will publish the plugin on the GerritForge's GitHub 
account and will start the integration process into the Jenkins CI organization.

Next steps?
A second iteration of the plugin would have a Declarative pipeline equivalent 
as well, which would require even less code required.
A third iteration of the plugin would support BlueOcean as well, to have a 
fully UX-integrated experience.
The goal is to have Gerrit Code Review to be a 1st class citizen in the Jenkins 
ecosystem :-)

So what happens to the Gerrit Trigger Plugin?
The new plugin is not going to replace the current Gerrit Trigger Plugin, but 
would rather represent an alternative to simpler scenarios when you just 
require a standard Jenkinsfile Gerrit validation workflow. For all the current 
users of the Gerrit Trigger Plugin things wouldn't change, unless they need a 
more Jenkisfile-integrated experience.

Feedback? Like it? Hate it? Have your say :-)

Luca.


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/D9530F31-F753-4339-AAF5-62449FFCC607%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.0 initial setup plugin selection

[Luca Milanesio]

Why BitBucket, GitLab, GitHub and not Gerrit?
Gerrit is 100% OpenSource, whilst the same cannot be said about the others ;-)

Luca.

> On 24 Feb 2016, at 12:51, Daniel Beck  wrote:
> 
> 
> On 24.02.2016, at 13:05, Victor Martinez  
> wrote:
> 
>> Mercurial and Perforce are not part of that list, although their usage are 
>> not massive compare to Git or SVN, but might be also important to have them 
>> as part of the SCM category. That's my point of view and sorry if I said 
>> something which it was already said previously.
> 
> Good point. As I wrote on the wiki, SCM plugins are special (nothing much 
> going on in Jenkins without them), so I recommend we're more accepting in 
> that category. My current list of SCMs to include are (with approx. install 
> count):
> 
> https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin - 76k
> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin - 123k
> https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin - 1500
> https://wiki.jenkins-ci.org/display/JENKINS/CVS+Plugin - 120k
> https://wiki.jenkins-ci.org/display/JENKINS/GitBucket+Plugin - 1200
> https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin - 20k
> https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Merge+Request+Builder+Plugin
>  - 2000
> https://wiki.jenkins-ci.org/display/JENKINS/GitLab+Plugin - 5800
> https://wiki.jenkins-ci.org/display/JENKINS/Mercurial+Plugin - 6500
> https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin - 1500
> https://wiki.jenkins-ci.org/display/JENKINS/Repo+Plugin - 1300
> https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin - 1000
> https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin - 
> 2900
> 
> While Perforce Plugin has more installs than P4, it stagnates, and its wiki 
> page recommends use of P4, which is rapidly growing.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/D05C72E9-6127-4260-A8FD-0FC3D2E77E3D%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/C55B2F53-1C25-4FA1-A3FF-F46F40B8EFA0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: forbid direct commits to master for core

[Luca Milanesio]

A few years ago the Gerrit workflow process was proposed, which can enforce a 
workflow on specific branches.
You can then have GitHub repos synchronised out-of-the-box.

See for instance the OpenStack project:
- Gerrit reviews: https://review.openstack.org 
- GitHub: https://github.com/openstack 

... or the Gerrit project itself :-)

- Gerrit reviews: https://gerrit-review.googlesource 
.com
- GitHub: https://github.com/gerritcodereview 

- Jenkins CI on the reviews: https://gerrit-ci.gerritforge.com 


It allows people to still push directly to some branches (e.g. experimental or 
devs) or submit PRs on GitHub ... but the overall workflow is managed by Gerrit.

Luca.

> On 21 Dec 2015, at 08:33, Oleg Nenashev  wrote:
> 
> Slightly hijacking this topic: would it be worthwhile having a similar 
> rule (even if it's may not be technically enforceable) for creating new 
> plugins? 
> 
> I'm +1 on it. My gut-feeling that there are misusages: forking of demo-only 
> plugins, bad namings, etc.
> It's enforceable. We could restrict the create repo permission to admins only.
> The restriction of the IRC bot is also possible when we have a "community 
> team".
> 
> The same for plugins, if *author* of plugin doesn’t want to use PRs, then you 
> can’t enforce him do it (the reason why i left docker-plugin development). 
> Core is critical for stability and relates to many devs/contributors, that’s 
> why i created this topic/proposal.
> 
> At least it's a good place to start.
> 
> I see lots of PRs languishing for ages with disagreement over what to do and 
> no clear outcome one way or the other...]
> 
> It's a complete off-topic in any case...
> Jenkins does not belong to CloudBees as well the company does not belong to 
> the project. All Jenkins contributors including CB-employed ones can 
> designate their review time as they want/can. Obviously we use our working 
> time to review "our" PRs, but it does not mean that nobody from CB reviews 
> other PRs during his spare time. Honestly I don't see much unreviewed PRs, 
> but if there are such ones you can always ask for a review in the ML. The old 
> pending PRs have been also classified. 
> 
> We have no "formal" PR review process in the community. If somebody drafts a 
> proposal, it would be a good topic for the discussion.
> 
> понедельник, 21 декабря 2015 г., 2:58:34 UTC+3 пользователь Stephen Connolly 
> написал:
> If we are going to go down the road of forbidding direct committing to master 
> and forcing people to go through PRs (let's assume we can find a way to let 
> release commits go through) we'd need a better criteria for when we can 
> actually merge PRs.
> 
> I see lots of PRs languishing for ages with disagreement over what to do and 
> no clear outcome one way or the other...
> 
> We have 25 PRs that are older than Jun 1st 2014...
> 
> 50 PRs that are at least 1 year old
> 
> 75 PRs that are 6 months or older
> 
> Now KS, it's not CloudBees place to decide what the community wants to have 
> merged... the community has not defined how to address these PRs...
> 
> If we are to move to PRs without direct commit then I want to see a defined 
> process whereby no PR goes more than say 1 month without the community 
> deciding if it is a Go / No Go on the general idea.
> 
> I am quite sure that CloudBees would be willing to help get PRs into a better 
> state for merging if we knew that those PRs were the direction the community 
> wanted to go. Right now we seem to end up saying "ok this is what we think, 
> here's our contribution, do you want it?" and there is no movement further... 
> after a while we then remove our CloudBees hat and don our core contributors 
> hat and say something like "ah for jebus's sake, nobody else has expressed an 
> opinion either way for the past 2-3 weeks, let's just merge it" but don't for 
> one second think that we like doing this.
> 
> I would say that the community needs to show interest in PRs before we can 
> switch to a PR model as the route for change.
> 
> My suggestion is that when a PR has been open for a week or so, the community 
> should start a vote thread to decide if the change is the right direction 
> (Go) or the wrong direction (No Go). If No Go then close the PR providing the 
> reason... if Go then the PR author can be helped to get the PR to a mergeable 
> quality and then we merge the change and move forward.
> 
> If that process gets all the open PRs down such that most PRs are open for no 
> more than 1 month, then and only then would I say that preventing direct core 
> commits might be worth pursuing... 
> 
> Just my €0.02
> 
> -Stephen 
> 
> On 20 December 2015 at 17:22, Andrew Bayer gmail.com 
> > wrote:
> So, addressing a few aspects of this thread:
> 
> - I'd strongly oppose ICLA/push permission

Re: Proposal: revisiting JUC in 2016

[Luca Milanesio]

> On 20 Oct 2015, at 23:12, Alyssa  wrote:
> 
> when JUC EU was planned - the goal has always been to find a central location 
> where folks from diff parts of EU can conveniently attend. But it didn't turn 
> out that way - mainly local people attended. And of course one big event in 
> EU is very costly.

Agreed … the London venue should have been *very very* expensive!
One world-wide location in USA would be better, more days and less travelling 
around the globe.

What about doing a streaming event for people in Europe and Asia to attend 
remotely?
Possibly organised in cooperation with SkillsMatters in the UK and other 
similar organisations in the rest of Europe.

Luca.

> The CB-Jenkins Summits will provide the oppty to bring Jenkins to local areas 
> as well as keep overhead down. 
> 
> On Tuesday, October 20, 2015 at 1:16:13 PM UTC-7, Kohsuke Kawaguchi wrote:
> Yes, the downside of not having JUC in Europe has been considered.
> 
> One of the problems we had in the past few years with JUC in Europe has been 
> that we have never managed to create a truly pan-Europe event. When we do JUC 
> in Paris, only French people came. Did one in Berlin and only Germans came. 
> This year was in London and neither German nor French came. So I believe a 
> part of what led into the proposal (and Alyssa can correct me if I'm wrong) 
> is that the European audience would be served better by CloudBees-Jenkins 
> Summit part of the proposal, which allows us to run a sizable local event in 
> multiple locations while controlling the production overhead (such as CfP, 
> organizing agenda, etc.)
> 
> 
> 2015-10-20 3:03 GMT-07:00 James Nord >:
> Taking off my cloudbees hat and putting on my old hat being based in Europe.
> 
> Getting approval to attend conferences abroad (outside Europe) for me was not 
> always easy - as it involves large travel and time lost due to this.  As such 
> it was easier to go to a european conference.   I also feel that yes you get 
> more people in USA-CA but that this could just a critical mass and a direct 
> result of its much easier to go to something local than it is to travel 9 
> hours around the globe.  Do you have stats of where people came from in the 
> last even - where they predominantly from the bay area?
> In the London event I met people that where very basic users of Jenkins (just 
> starting) and it was easy for them to go to a local conference.  Would these 
> same users make the same investment to go somewhere accross the globe - I 
> personally don't think so - which would be a big shame.
> 
> The JAMs fill a gap - but I'm not sure that this gap is filled yet - or that 
> it will be filled by next year  - certainly there is nothing in the UK that I 
> know of - and even then we would need something based in the north west as 
> well as somewhere around London.
> 
> 
> On Tuesday, October 20, 2015 at 4:51:39 AM UTC+2, Kohsuke Kawaguchi wrote:
> Putting my CloudBees hat on, I'd like to discuss the following proposed 
> changes to the events in 2016, where we are moving away from JUC into a new 
> model.
> 
> https://wiki.jenkins-ci.org/display/JENKINS/Proposal+-+Revisiting+JUC+in+2016 
> 
> 
> I put this up for the project meeting agenda in 1.5 week, but I hope to get 
> discussions going well before that.
> 
> -- 
> Kohsuke Kawaguchi
> 
> -- 
> 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/fd26a289-b46b-4c38-a8b0-34bcfc50feab%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Kohsuke Kawaguchi
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/0a84666c-6a00-4489-8350-51c5e0cebaf8%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsu

302 and 502 from curl -v http://updates.jenkins-ci.org/update-center.json

[Luca Milanesio]

Hi all,
this morning I have issues when building my Jenkins Docker image that 
automatically download / install plugins.

The
curl -v http://updates.jenkins-ci.org/update-center.json 


sometimes fails with a 502 and sometimes returns a 302.

Does anyone have the same problem?

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/760C76E0-DC31-4535-BE54-49135740C301%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Gerrit issue with drafts

[Luca Milanesio]

Really like the "Build +1" flag option: it would be an even more explicit 
tracking of "ready to be built" status, to avoid the painful and expensive 
waste of build resources.

Luca.

On 8 May 2014, at 09:19, Sandell, Robert  wrote:

> Perhaps Gerrit is sending patchset-created events to users that are invited 
> to the draft change, and since one patch set is revealed to the Jenkins user 
> and Jenkins then has posted a comment on the patch set it's considered to be 
> able to view the draft.
>  
> Unless you have other reasons for using the draft method than to hide the 
> changes from Jenkins; you could change your jobs to trigger when the patch 
> set gets a "code review +2" or any custom label like "build +1". It would 
> have the same effect in that it would not trigger until a code review is done.
>  
>  
> Robert Sandell
> Sony Mobile Communications
> Tel: +46 10 80 12721
> sonymobile.com
>  
> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] 
> On Behalf Of Jens Löök
> Sent: den 7 maj 2014 15:31
> To: jenkinsci-dev@googlegroups.com
> Cc: Jens Löök
> Subject: Re: Gerrit issue with drafts
>  
> I don't think so, as far as I can tell it is not possible to figure out that 
> a draft on top of a public change-set actually is a draft from the message 
> that is sent. But in the Gerrit gui the new change-set is marked as a draft. 
> So the message that is picked up by the Gerrit trigger in Jenkins does not 
> get the same information as the gui.
>  
> /Jens 
> 
> Den onsdagen den 7:e maj 2014 kl. 14:01:30 UTC+2 skrev lucamilanesio:
> Seems like a Gerrit-trigger-plugin issue rather than Gerrit.
> Have you shared it on the Jenkins mailing list ?
> 
> Sent from my iPhone
> 
> On 7 May 2014, at 12:39, Jens Löök  wrote:
> 
> Hi
> I sent this issue on our internal mailing list at Ericsson and it was 
> suggested to post it here as well it would be interesting to hear your 
> thoughts on this matter. 
> I did a quick search but nothing to obvious came up so I hope I'm not posting 
> something that comes up a lot here. 
>  
> We have defined a work flow where we use drafts in Gerrit to lighten the load 
> on our build machinery a bit. The scenario is that you can get the review out 
> of the way before you actually trigger the build and test jobs.
>  
> We are using "git-review" addon to submit changes to Gerrit and we have 
> changed the default behavior of git-review to always create drafts, you can 
> still submit with -P to get a public change (it is configurable for each repo 
> if the default action should be publish or draft).
>  
> Now to our issue, if you have a change that contains one or several draft 
> patch-sets and then you make the change public either by pushing the Publish 
> button in the gui or by creating a new patch-set that is public our review 
> job will be triggered. And if you need to create additional patch-sets to fix 
> any problem in the review job all new patch-sets will trigger the review job 
> no matter if you send them to refs/drafts och refs/publish. If you create a 
> new draft change-set on top of a public change-set the review job will be 
> kicked off because the "patchset-created" message from Gerrit contains 
> "status":"NEW" but in the GUI the new patch-set will have status DRAFT and 
> you will need to do publish before you can do submit and this will trigger 
> two review-jobs for the same patch-set.
>  
> To me it seems like Gerrit is a bit inconsistent here and the behavior should 
> be changed so that
>   - a new draft patch-set on top of a public patch-set does not trigger a 
> build, the message from Gerrit should still contain"status":"DRAFT" .
>   or
>   - a new draft patch-set on top of a public patch-set becomes a public 
> change by default and you do not need to publish it before it can be 
> submitted.
> -- 
> -- 
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenki

Re: Gerrit issue with drafts

[Luca Milanesio]

Seems like a Gerrit-trigger-plugin issue rather than Gerrit.
Have you shared it on the Jenkins mailing list ?

Sent from my iPhone

> On 7 May 2014, at 12:39, Jens Löök  wrote:
> 
> Hi
> I sent this issue on our internal mailing list at Ericsson and it was 
> suggested to post it here as well it would be interesting to hear your 
> thoughts on this matter. 
> I did a quick search but nothing to obvious came up so I hope I'm not posting 
> something that comes up a lot here. 
> 
> We have defined a work flow where we use drafts in Gerrit to lighten the load 
> on our build machinery a bit. The scenario is that you can get the review out 
> of the way before you actually trigger the build and test jobs.
> 
> We are using "git-review" addon to submit changes to Gerrit and we have 
> changed the default behavior of git-review to always create drafts, you can 
> still submit with -P to get a public change (it is configurable for each repo 
> if the default action should be publish or draft).
> 
> Now to our issue, if you have a change that contains one or several draft 
> patch-sets and then you make the change public either by pushing the Publish 
> button in the gui or by creating a new patch-set that is public our review 
> job will be triggered. And if you need to create additional patch-sets to fix 
> any problem in the review job all new patch-sets will trigger the review job 
> no matter if you send them to refs/drafts och refs/publish. If you create a 
> new draft change-set on top of a public change-set the review job will be 
> kicked off because the "patchset-created" message from Gerrit contains 
> "status":"NEW" but in the GUI the new patch-set will have status DRAFT and 
> you will need to do publish before you can do submit and this will trigger 
> two review-jobs for the same patch-set.
> 
> To me it seems like Gerrit is a bit inconsistent here and the behavior should 
> be changed so that
>   - a new draft patch-set on top of a public patch-set does not trigger a 
> build, the message from Gerrit should still contain"status":"DRAFT" .
>   or
>   - a new draft patch-set on top of a public patch-set becomes a public 
> change by default and you do not need to publish it before it can be 
> submitted.
> -- 
> -- 
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intellij License Renewal

[Luca Milanesio]

I used the IntelliJ 13 for a while ... and I went back to Ver. 12 :-(

Luca.

On 12 Mar 2014, at 13:52, Aldrin Leal  wrote:

> me too! (AWSEB Deployment Plugin)
> 
> --
> -- Aldrin Leal, 
> Master your EC2-fu! Get the latest ekaterminal public beta 
> http://www.ingenieux.com.br/products/ekaterminal/
> 
> 
> On Wed, Mar 12, 2014 at 10:49 AM, Richard Lavoie  
> wrote:
> I'd like to have it too,
> 
> Trying to update the selenium plugin after so long...
> 
> Richard
> 
> 
> On Mon, Aug 5, 2013 at 2:12 PM, Kohsuke Kawaguchi  
> wrote:
> 
> I got the new key, so those of you who need it, please let me know (along 
> with what plugins you work on, as a due diligence.)
> 
> On 08/03/2013 07:25 AM, Stefan Wolf wrote:
> Hi,
> 
> the Intellij License for the Jenkins project will expire on August 7. Is the
> renewal already under way?
> 
> Best regards,
> Stefan
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> 
> -- 
> Richard Lavoie
> IT consultant / consultant en informatique
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins validated merge plugin

[Luca Milanesio]

Hi all,

I am looking at the new Jenkins Validated Merge plugin from Cloudbees 
(http://jenkins-enterprise.cloudbees.com/docs/user-guide-bundle/validated-merge-sect-tutorial.html)
 and I am puzzled on one feature:
"Unlike Gerrit+Jenkins integration, in which each commit is separately built 
and tested, the validated merge in Jenkins only checks the tip of the ref. So 
you can split your change into several logically separated pieces, without 
paying the penalty of more build time"

If you have a build that includes 5 commits by 5 different people, how can the 
validated merge plugin understand "who broke what" ?

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commit loss prevention

[Luca Milanesio]

On 14 Nov 2013, at 18:23, Kohsuke Kawaguchi  wrote:

> On 11/13/2013 11:58 PM, Luca Milanesio wrote:
>> We need to make some tests on the scalability of the events API because of:
>> 1) need to monitor over 1000 repos (one call per repo ? one call for all ?)
>> 2) by monitoring the entire jenkinsci org, 300 events could be not enough in 
>> case of catastrophic events
> 
> The good news is that the push that removes/alters refs also take time. I 
> have the notification e-mail from your push to 186 repos, and it spans over 
> an hour.

True: however possibly the notifications took an hour but the push was pretty 
fast but still around 25 / min. 300 events per minute should be then fairly 
enough :-)
The only way to go over that limit is parallel push by multiple accounts ... 
but that I would say is very unlikely.

> 
> So I'm hoping that polling 300 events every minute would cover us pretty 
> well. And like you say, a webhook can help us reduce this window down even 
> further.

Yep.

> 
> 
> There's another reason I'm optimistic about this scheme.
> 
> Suppose you are maliciously trying to cause data loss. If we are regularly 
> recording refs, you have to mount an attack immediately after some commits go 
> in so as to overwhelm the 300 event buffer, then keep that saturation going 
> so that your ref updates/removals will also be dropped from the event buffer. 
> And even with this much effort you can only cause the data loss of the 
> commits that went in right before yours.
> 
> So I think it makes the attack so ineffective that we can tolerate that risk, 
> and I find it unlikely that no accidents will look like this.

Agreed.

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commit loss prevention

[Luca Milanesio]

We need to make some tests on the scalability of the events API because of:
1) need to monitor over 1000 repos (one call per repo ? one call for all ?)
2) by monitoring the entire jenkinsci org, 300 events could be not enough in 
case of catastrophic events

Working at webhook level ? I'll investigate further about the reliability / 
scalability of the API (on a series of *test* repo *OUTSIDE* the Jenkins CI 
organisation)

Luca.

On 13 Nov 2013, at 18:56, Kohsuke Kawaguchi  wrote:

> 
> On 11/11/2013 11:05 PM, Luca Milanesio wrote:
>> Seems a very good idea, it is basically a remote audit trail.
>> 
>> The only concern is the throttling on the GitHub API: it would be better
>> then to do the scripting on a local mirror of the GitHub repos. When you
>> receive a forced update you do have anyway all the previous commits and
>> the full reflog.
> 
> With respect to throttling, the events API is designed for polling [1], so we 
> just need to poll the events for the entire jenkinsci org [2] and we'll have 
> the whole history.
> 
> We already do an equivalent of local mirrors of the GitHub repos in 
> http://git.jenkins-ci.org/. The problem is that reflogs do not record remote 
> ref updates, so it will not protect against accidental ref manipulations.
> 
> It does help however for the purpose of retaining commit objects, so we need 
> to keep this.
> 
> 
>> However as you said by being triggered via web hook the number of API
>> calls can be reduced to the minimum.
>> 
>> I would submit a proposal to the Git mailing list of a "fetch by SHA1"
>> which is a missing feature in Git IMHO.
> 
> My recollection is that this was intentional for the security reason, so that 
> if a push is made accidentally and if it's removed, then those objects 
> shouldn't be accessible.
> 
> I think what's useful and safe is to allow us to create a ref remotely on an 
> object that doesn't exist locally. Again, the transport level protocol allows 
> this, so it'd be nice to expose this.
> 
>> Thanks to everyone including GitHub for the help and cooperation in
>> getting this sorted out !!
> 
> [1] http://developer.github.com/v3/activity/events/
> [2] https://api.github.com/orgs/jenkinsci/events
> 
>> 
>> Luca
>> -
>> Sent from my iPhone
>> Luca Milanesio
>> Skype: lucamilanesio
>> 
>> 
>> On 12 Nov 2013, at 06:25, Kohsuke Kawaguchi > <mailto:k...@kohsuke.org>> wrote:
>> 
>>> Now that the commits have been recovered and things are almost back to
>>> normal, I think it's time to think about how to prevent this kind of
>>> incidents in the future.
>>> 
>>> Our open commit access policy was partly made possible by the idea
>>> that any bad commits can be always rolled back. But where I failed to
>>> think through was that the changes to refs aren't by themselves
>>> version controlled, and so it is possible to lose commits by incorrect
>>> ref manipulation, such as "git push -f", or by deleting a branch.
>>> 
>>> I still feel strongly that we maintain the open commit access policy.
>>> This is how we've been operating for the longest time, and it's also
>>> because otherwise adding/removing developers to repositories would be
>>> prohibitively tedious.
>>> 
>>> So my proposal is to write a little program that uses GitHub events
>>> API to keep track of push activities in our repositories. For every
>>> update to a ref in the repository, we can record the timestamp, SHA1
>>> before and after, the user ID. We can maintain a text file for every
>>> ref in every repository, and the program can append lines to it. In
>>> other words, effectively recreate server-side reflog outside GitHub.
>>> 
>>> The program should also fetch commits, so that it has a local copy for
>>> every commit that ever landed on our repositories. Doing this also
>>> allows the program to detect non fast-forward. It should warn us in
>>> that situation, plus it will create a ref on the commit locally to
>>> prevent it from getting lost.
>>> 
>>> We can then make these repositories accessible via rsync to encourage
>>> people to mirror them for backup, or we can make them publicly
>>> accessible by hosting them on GitHub as well, although the latter
>>> could be confusing.
>>> 
>>> WIth a scheme like this, pushes can be safely recorded within a minute
>>> or so (and this number can go down even further if we use webhooks.)
>>

Re: Commit loss prevention

[Luca Milanesio]

Yes, it would be nice to be able to allow the people to auto-remove himself 
from push permissions to the repos he does not use.
For instance I normally push to no more than 5-6 repos, I should then be able 
to auto-restrict myself to those ones only.

Luca.

On 13 Nov 2013, at 19:00, Kohsuke Kawaguchi  wrote:

> 
> OK, that's a fair point.
> 
> I do recall writing a daemon that cleans up access control on repositories 
> (among other things like disabling issue tracker), but I'm not too sure if we 
> are running it regularly or not.
> 
> Maybe we can extend https://jenkins-ci.org/account so that people can 
> add/remove access to repositories by themselves? But then that means we will 
> get rid of the need to ask in the mailing list.
> 
> 
> 
> On 11/12/2013 02:05 AM, Christopher Orr wrote:
>> On 12/11/13 07:25, Kohsuke Kawaguchi wrote:
>>> I still feel strongly that we maintain the open commit access policy.
>>> This is how we've been operating for the longest time, and it's also
>>> because otherwise adding/removing developers to repositories would be
>>> prohibitively tedious.
>> 
>> I agree that the policy of allowing everyone to have a repo and to
>> commit relatively freely remains a good idea, but having the option to
>> give new developers push access to 1100 repositories due to how GitHub
>> teams and our IRC bot work is an issue that has been been raised before:
>> 
>> https://groups.google.com/d/msg/jenkinsci-dev/-Yk0UFfSPZc/GzOu5b1AP7QJ
>> 
>> 
>> Would it be reasonable to suggest that we remove the option to add
>> people to the "Everyone" team from IRC and, if GitHub still adds
>> newly-forked repos to every team by default, that we have some sort of
>> process to automatically clean up the teams, as mentioned in that thread?
>> 
>> Regards,
>> Chris
>> 
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commit loss status update

[Luca Milanesio]

Hi Kohsuke,
that's really good news !

I would like once again to publicly apologise with all the Jenkins Developers 
Community for the inconvenience caused by my forced push on the 10th of 
November.
The problem was caused by the unfortunate combination of fatal mistakes on my 
side: not the tool's (Git, Gerrit or GitHub) fault ... just a very bad day of 
mistakes from me :-(

A big thank to all the people that cooperated and supported the recover the 
correct point on 186 repositories (!) including Kohsuke and Nathan.
I am keen to help in the post-mortem report and analysis in order to help the 
community to avoid that similar situations would happen in the future.

Thanks again for your understanding.

Luca.

On 13 Nov 2013, at 02:13, Kohsuke Kawaguchi  wrote:

> 
> I merged the three repositories and pushed new master.
> 
> > puppet-jenkins
>> view-job-filters-plugin
>> xvnc-plugin
> 
> This concludes the data recovery. All the commits have been restored, all the 
> branches have been updated, and there's no action needed by anyone.
> 
> That said, it'd be great if people can test my claim by trying to find any 
> missing commits, to boost our confidence level in the recovery process (or 
> find missing commits while we can still save them.)
> 
> I'll work with Luca to write a summary on the incident and the data recovery.
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commits and refs affected by "git push -f"

[Luca Milanesio]

Hi Kohsuke,
see below my feedback.

On 12 Nov 2013, at 23:38, Kohsuke Kawaguchi  wrote:

> On 11/12/2013 03:13 PM, Luca Milanesio wrote:
>> d) The repos with not enough history or depth
>> 
>> None of those repositories were in the list of the 186 ones mentioned: can't 
>> find any of them on my logs.
>> This means that in the event time window captured by GitHub there wasn't any 
>> activity related to my account or any activity at all.
> 
> Maybe you have already explained this elsewhere, but how did you come up with 
> the list of 186 repositories in the first place? Is that what you had on your 
> Gerrit instance when it did "git push -f"?

It was not a manual command execution of "git push -f" but an uncontrolled 
(from my side) behaviour of the Gerrit replication plugin.
The "force" option is (unlucky choice IMHO) implicit and optional: if you don't 
say anything (as I did) assumes force by default ;-(

As I do have the logs (on my side) of the catastrophe happened on Sun 10th, I 
extracted the list of repositories from there.

> 
> The repositories listed under "[WARNING] events don't go back far enough" are 
> repositories that do report some events but none before the Nov 9th. Thus 
> there's a suspicion that some of those event history was already lost, hence 
> the warning. There are only three, and I think all is accouned for:
> 
> - awseb-deployment-plugin   (created yesterday)
> - backend-git-pushf-finder  (created today)
> - websphere-deployer-plugin (created today)
> 
> 
> Repositories listed under "[INFO   ] no events in" are more numerous.  I 
> agree with you that most likely there has been no activities for these 
> repositories in quite some time. For now I think we'd have to assume that no 
> commits were lost on them.
> 
> (If we have more cycles we could check the last commit in these repos to 
> really verify that none of them contain any new commits)
> 
>> --- * ---
>> 
>> My suggestions:
>> 
>> a) I guess this is due of some initial 'git push' made for recovering
>> the situation at the timethat GitHub took the snapshot (the post-push
>> are mostly incorrect, not the pre-push)
> 
> Agreed.
> 
> 
>> b) I will make further analysis on the 4 exceptions
>> 
>> c) Those branches are definitely to be restored, using the pre-push SHA1 
>> from Kohsuke's list
>> 
>> d) Possibly cross-check with the plugins maintainers, but they should be OK 
>> and not require fixing.
> 
> Yes, let's list up the repos of (b)+(c) above and find maintainers.
> 
> 
>> --- * ---
>> 
>> Any other thoughts / feedback ?
>> 
>> Luca.
>> 
>> 
>> On 12 Nov 2013, at 22:34, Luca Milanesio  wrote:
>> 
>>> I will cross-check with the list provided by GitHub.
>>> (was doing a similar exercise on the suspect 54 repos anyway)
>>> 
>>> Luca.
>>> 
>>> On 12 Nov 2013, at 21:27, Kohsuke Kawaguchi  wrote:
>>> 
>>>> 
>>>> As I suggested in the e-mail thread, I've written a little program that 
>>>> looks at the GitHub events API to figure out the push activities from 
>>>> Luca, and assembled a list of refs and affected commits. The result is in 
>>>> [1].
>>>> 
>>>> The exact code is at [2], and I invite others to check my sanity. The 
>>>> basic idea is to look at the events time line, and find the problematic 
>>>> push.
>>>> 
>>>> The meaning of the output is:
>>>> 
>>>> repository name, before, after, ref
>>>> 
>>>> "before" is the commit that's lost.
>>>> 
>>>> I'm going to compare this with the CSV file from GitHub now to see if 
>>>> there's a pattern of discrepancy here.
>>>> 
>>>> [1] https://gist.github.com/kohsuke/7438914
>>>> [2] 
>>>> https://github.com/jenkinsci/backend-git-pushf-finder/tree/eeb462c47dbaa45f2170ccada487eed33da81193
>>>> --
>>>> Kohsuke Kawaguchi  http://kohsuke.org/
>>>> 
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>> 
>> 
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commits and refs affected by "git push -f"

[Luca Milanesio]

Cross-checking the two lists I have noticed:

a) The list from GitHub has lots of apparently incorrect post-push SHA-1 
according to Kohsuke's list (88 repos)

b) With regards to the pre-push SHA-1, the two lists are almost identical with 
the following 4 exceptions:

git-client-plugin => pre-push and post-push inverted between the two lists
humbug-plugin => pre-push and post-push (GitHub) corresponds to the post-push 
(Kohsuke)
promoted-builds-plugin  => pre-push and post-push (GitHub) corresponds to the 
post-push (Kohsuke)
scoring-load-balancer-plugin => pre-push and post-push (GitHub) corresponds to 
the post-push (Kohsuke)

c) There are repositories where the push was actually on other branches 

 git-plugin,refs/heads/refactoring
 json-lib,refs/heads/rebase-2.4
 perforce-plugin,refs/heads/multiple-scm-instatination-fix
 pitmutation-plugin,refs/heads/generic-metrics
 prqa-plugin,refs/heads/1.2.1
 skype-im-plugin,refs/heads/v2dev
 stashnotifier-plugin,refs/heads/develop
 subversion-plugin,refs/heads/refactoring
 transifex-plugin,refs/heads/gh-pages

d) The repos with not enough history or depth

None of those repositories were in the list of the 186 ones mentioned: can't 
find any of them on my logs.
This means that in the event time window captured by GitHub there wasn't any 
activity related to my account or any activity at all.

--- * ---

My suggestions:

a) I guess this is due of some initial 'git push' made for recovering the 
situation at the time that GitHub took the snapshot (the post-push are mostly 
incorrect, not the pre-push)

b) I will make further analysis on the 4 exceptions

c) Those branches are definitely to be restored, using the pre-push SHA1 from 
Kohsuke's list

d) Possibly cross-check with the plugins maintainers, but they should be OK and 
not require fixing.

--- * ---

Any other thoughts / feedback ?

Luca.


On 12 Nov 2013, at 22:34, Luca Milanesio  wrote:

> I will cross-check with the list provided by GitHub.
> (was doing a similar exercise on the suspect 54 repos anyway)
> 
> Luca.
> 
> On 12 Nov 2013, at 21:27, Kohsuke Kawaguchi  wrote:
> 
>> 
>> As I suggested in the e-mail thread, I've written a little program that 
>> looks at the GitHub events API to figure out the push activities from Luca, 
>> and assembled a list of refs and affected commits. The result is in [1].
>> 
>> The exact code is at [2], and I invite others to check my sanity. The basic 
>> idea is to look at the events time line, and find the problematic push.
>> 
>> The meaning of the output is:
>> 
>>  repository name, before, after, ref
>> 
>> "before" is the commit that's lost.
>> 
>> I'm going to compare this with the CSV file from GitHub now to see if 
>> there's a pattern of discrepancy here.
>> 
>> [1] https://gist.github.com/kohsuke/7438914
>> [2] 
>> https://github.com/jenkinsci/backend-git-pushf-finder/tree/eeb462c47dbaa45f2170ccada487eed33da81193
>> -- 
>> Kohsuke Kawaguchi  http://kohsuke.org/
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commits and refs affected by "git push -f"

[Luca Milanesio]

I will cross-check with the list provided by GitHub.
(was doing a similar exercise on the suspect 54 repos anyway)

Luca.

On 12 Nov 2013, at 21:27, Kohsuke Kawaguchi  wrote:

> 
> As I suggested in the e-mail thread, I've written a little program that looks 
> at the GitHub events API to figure out the push activities from Luca, and 
> assembled a list of refs and affected commits. The result is in [1].
> 
> The exact code is at [2], and I invite others to check my sanity. The basic 
> idea is to look at the events time line, and find the problematic push.
> 
> The meaning of the output is:
> 
>   repository name, before, after, ref
> 
> "before" is the commit that's lost.
> 
> I'm going to compare this with the CSV file from GitHub now to see if there's 
> a pattern of discrepancy here.
> 
> [1] https://gist.github.com/kohsuke/7438914
> [2] 
> https://github.com/jenkinsci/backend-git-pushf-finder/tree/eeb462c47dbaa45f2170ccada487eed33da81193
> -- 
> Kohsuke Kawaguchi  http://kohsuke.org/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

I'm just checking using the GitHub  GUI, will not push anything :-) 

I am trying the get the final list of repos that would need further fixing. 
Then would leave to the plugin maintainer to judge which is the latest, as it 
was not detected by the GitHub support team.

Luca
-
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio


On 12 Nov 2013, at 20:01, Slide  wrote:

> Please don't run any more scripts :-). The email-ext-plugin is just fine, 
> please take it off your list for needing recovery.
> 
> 
> On Tue, Nov 12, 2013 at 12:35 PM, Luca Milanesio  
> wrote:
>> I've checked as well and tfs-plugin was in the list of recovered repos but I 
>> can't find the recovery branch either:
>> https://api.github.com/repos/jenkinsci/tfs-plugin/branches/recovery
>> 
>> Will run a quick script for assess the situation with the others.
>> 
>> In the meantime I've extracted the lists of repos with pre-push and 
>> post-push SHA1 are the same (54 repos):
>> artifactory-plugin
>> branch-api-plugin
>> build-timeout-plugin
>> ci-game-plugin
>> clearcase-plugin
>> clearcase-ucm-plugin
>> collabnet-plugin
>> collapsing-console-sections-plugin
>> compress-artifacts-plugin
>> copy-project-link-plugin
>> copy-to-slave-plugin
>> credentials-plugin
>> crowd-plugin
>> crowd2-plugin
>> disable-failed-job-plugin
>> ec2-plugin
>> email-ext-plugin
>> gerrit-trigger-plugin
>> git-chooser-alternative-plugin
>> gitbucket-plugin
>> groovy-postbuild-plugin
>> humbug-plugin
>> jacoco-plugin
>> job-poll-action-plugin
>> jobConfigHistory-plugin
>> json-lib
>> leiningen-plugin
>> logfilesizechecker-plugin
>> mailer-plugin
>> maven-hpi-plugin
>> maven-info-plugin
>> nerrvana-plugin
>> next-build-number-plugin
>> next-executions-plugin
>> perforce-plugin
>> pitmutation-plugin
>> promoted-builds-plugin
>> prqa-plugin
>> rvm-plugin
>> scm-api-plugin
>> scm2job-plugin
>> scoring-load-balancer-plugin
>> selenium-tests
>> skype-im-plugin
>> ssh-agent-plugin
>> ssh-credentials-plugin
>> ssh-slaves-plugin
>> stashnotifier-plugin
>> subversion-plugin
>> swarm-plugin
>> transifex-plugin
>> vstestrunner-plugin
>> warnings-plugin
>> ws-cleanup-plugin
>> 
>> Will check now their master SHA1 and compare with the one "post-push" to see 
>> if the plugins maintainers have already pushed it or not.
>> 
>> Luca.
>> 
>> On 12 Nov 2013, at 14:04, Olivier Dagenais  
>> wrote:
>> 
>>> Hi,
>>> 
>>> I learned of this situation last night.  I'm the [current] maintainer of 
>>> the tfs-plugin and I don't see commits since I released version 2.0, nor do 
>>> I see a 'recovery' branch at https://github.com/jenkinsci/tfs-plugin
>>> 
>>> The machine I last made release 3.0.1 from has a clone with the 24 missing 
>>> commits, and it looks like I should be able to just push them.
>>> 
>>> I don't want to interfere with any mass-fixing attempts discussed here 
>>> (especially by Kohsuke), so please let me know if I should proceed.
>>> 
>>> Thanks!
>>> - Oli
>>> P.S.: I'm the one who released the last rake-plugin (which sort of makes me 
>>> a maintainer), but the last commit to that repo was long enough ago that it 
>>> wasn't affected.
>>> 
>>> On Monday, November 11, 2013 5:22:55 PM UTC-5, lucamilanesio wrote:
>>>> 
>>>> Good news from GitHub: they have extracted the full list of SHA-1 before 
>>>> the forced push ! 
>>>> Many thanks to Nathan Witmer :-) 
>>>> 
>>>> See below the full CSV with the SHA-1. 
>>>> He created as well a branch named 'recovery' that points to the candidate 
>>>> point for restoring the master branch. 
>>>> 
>>>> Hope this will help to sort out the remaining repos. 
>>>> 
>>>> Luca. 
>>>> 
>>>> > Hi Luca. 
>>>> > 
>>>> > Oh man, that sinking feeling! 
>>>> > 
>>>> > But, no worries: I've gone through each of the repos listed above and 
>>>> > done the following: 
>>>> > 
>>>> > * retrieved the SHA for the previous `master` before you force-pushed 
>>>> > * created a branch called `recovery` pointing to each former master 
>>>> > 
>>>&g

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Ah ok :-) that is clarified then !

I'm looking now the list of 54 repos to see if they have been already fixed by 
their maintainers 

Will provide further updates later.

Luca
-
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio


On 12 Nov 2013, at 19:44, Kohsuke Kawaguchi  wrote:

> 
> The tfs-plugin repository that I obtained yesterday does contain the recovery 
> branch pointing at f61f3fc4a395c40196fd51838bd4dc07b87bd139, which is the tip 
> of the master before luca's commit according to 
> https://api.github.com/repos/jenkinsci/tfs-plugin/events
> 
> git ls-remote that I just run also agrees with that:
> 
>> % git ls-remote https://github.com/jenkinsci/tfs-plugin.git
>> 12b7198ce3b9ca2c940f3d995e64c481b22069b6HEAD
>> 12b7198ce3b9ca2c940f3d995e64c481b22069b6refs/heads/master
>> f61f3fc4a395c40196fd51838bd4dc07b87bd139refs/heads/recovery
>> d20b66b6f2af787faf1810f3e3af70bc354caa4crefs/heads/svn
>> af49749cda406363888b3fd371193de0d1fe3d72refs/heads/useTfsSdk
>> 341fd55cc2765aee9a893d03f7a1fab507b86925refs/meta/config
> ...
> 
> It's probably just not showing up in the UI presumably because the recovery 
> branch was created by an unusual means.
> 
> 
> On 11/12/2013 11:35 AM, Luca Milanesio wrote:
>> I've checked as well and tfs-plugin was in the list of recovered repos
>> but I can't find the recovery branch either:
>> https://api.github.com/repos/jenkinsci/tfs-plugin/branches/recovery
>> 
>> Will run a quick script for assess the situation with the others.
>> 
>> In the meantime I've extracted the lists of repos with pre-push and
>> post-push SHA1 are the same (54 repos):
>> artifactory-plugin
>> branch-api-plugin
>> build-timeout-plugin
>> ci-game-plugin
>> clearcase-plugin
>> clearcase-ucm-plugin
>> collabnet-plugin
>> collapsing-console-sections-plugin
>> compress-artifacts-plugin
>> copy-project-link-plugin
>> copy-to-slave-plugin
>> credentials-plugin
>> crowd-plugin
>> crowd2-plugin
>> disable-failed-job-plugin
>> ec2-plugin
>> email-ext-plugin
>> gerrit-trigger-plugin
>> git-chooser-alternative-plugin
>> gitbucket-plugin
>> groovy-postbuild-plugin
>> humbug-plugin
>> jacoco-plugin
>> job-poll-action-plugin
>> jobConfigHistory-plugin
>> json-lib
>> leiningen-plugin
>> logfilesizechecker-plugin
>> mailer-plugin
>> maven-hpi-plugin
>> maven-info-plugin
>> nerrvana-plugin
>> next-build-number-plugin
>> next-executions-plugin
>> perforce-plugin
>> pitmutation-plugin
>> promoted-builds-plugin
>> prqa-plugin
>> rvm-plugin
>> scm-api-plugin
>> scm2job-plugin
>> scoring-load-balancer-plugin
>> selenium-tests
>> skype-im-plugin
>> ssh-agent-plugin
>> ssh-credentials-plugin
>> ssh-slaves-plugin
>> stashnotifier-plugin
>> subversion-plugin
>> swarm-plugin
>> transifex-plugin
>> vstestrunner-plugin
>> warnings-plugin
>> ws-cleanup-plugin
>> 
>> Will check now their master SHA1 and compare with the one "post-push" to
>> see if the plugins maintainers have already pushed it or not.
>> 
>> Luca.
>> 
>> On 12 Nov 2013, at 14:04, Olivier Dagenais > <mailto:olivier.dagen...@gmail.com>> wrote:
>> 
>>> Hi,
>>> 
>>> I learned of this situation last night.  I'm the [current] maintainer
>>> of the tfs-plugin and I don't see commits since I released version
>>> 2.0, nor do I see a 'recovery' branch at
>>> https://github.com/jenkinsci/tfs-plugin
>>> 
>>> The machine I last made release 3.0.1 from has a clone with the 24
>>> missing commits, and it looks like I should be able to just push them.
>>> 
>>> I don't want to interfere with any mass-fixing attempts discussed here
>>> (especially by Kohsuke), so please let me know if I should proceed.
>>> 
>>> Thanks!
>>> - Oli
>>> P.S.: I'm the one who released the last rake-plugin (which sort of
>>> makes me a maintainer), but the last commit to that repo was long
>>> enough ago that it wasn't affected.
>>> 
>>> On Monday, November 11, 2013 5:22:55 PM UTC-5, lucamilanesio wrote:
>>> 
>>>Good news from GitHub: they have extracted the full list of SHA-1
>>>before the forced push !
>>>Many thanks to Nathan Witmer :-)
>>> 
>>>See below the full CSV with the SHA-1.
>>>He created as well a branch 

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

I've checked as well and tfs-plugin was in the list of recovered repos but I 
can't find the recovery branch either:
https://api.github.com/repos/jenkinsci/tfs-plugin/branches/recovery

Will run a quick script for assess the situation with the others.

In the meantime I've extracted the lists of repos with pre-push and post-push 
SHA1 are the same (54 repos):
artifactory-plugin
branch-api-plugin
build-timeout-plugin
ci-game-plugin
clearcase-plugin
clearcase-ucm-plugin
collabnet-plugin
collapsing-console-sections-plugin
compress-artifacts-plugin
copy-project-link-plugin
copy-to-slave-plugin
credentials-plugin
crowd-plugin
crowd2-plugin
disable-failed-job-plugin
ec2-plugin
email-ext-plugin
gerrit-trigger-plugin
git-chooser-alternative-plugin
gitbucket-plugin
groovy-postbuild-plugin
humbug-plugin
jacoco-plugin
job-poll-action-plugin
jobConfigHistory-plugin
json-lib
leiningen-plugin
logfilesizechecker-plugin
mailer-plugin
maven-hpi-plugin
maven-info-plugin
nerrvana-plugin
next-build-number-plugin
next-executions-plugin
perforce-plugin
pitmutation-plugin
promoted-builds-plugin
prqa-plugin
rvm-plugin
scm-api-plugin
scm2job-plugin
scoring-load-balancer-plugin
selenium-tests
skype-im-plugin
ssh-agent-plugin
ssh-credentials-plugin
ssh-slaves-plugin
stashnotifier-plugin
subversion-plugin
swarm-plugin
transifex-plugin
vstestrunner-plugin
warnings-plugin
ws-cleanup-plugin

Will check now their master SHA1 and compare with the one "post-push" to see if 
the plugins maintainers have already pushed it or not.

Luca.

On 12 Nov 2013, at 14:04, Olivier Dagenais  wrote:

> Hi,
> 
> I learned of this situation last night.  I'm the [current] maintainer of the 
> tfs-plugin and I don't see commits since I released version 2.0, nor do I see 
> a 'recovery' branch at https://github.com/jenkinsci/tfs-plugin
> 
> The machine I last made release 3.0.1 from has a clone with the 24 missing 
> commits, and it looks like I should be able to just push them.
> 
> I don't want to interfere with any mass-fixing attempts discussed here 
> (especially by Kohsuke), so please let me know if I should proceed.
> 
> Thanks!
> - Oli
> P.S.: I'm the one who released the last rake-plugin (which sort of makes me a 
> maintainer), but the last commit to that repo was long enough ago that it 
> wasn't affected.
> 
> On Monday, November 11, 2013 5:22:55 PM UTC-5, lucamilanesio wrote:
> Good news from GitHub: they have extracted the full list of SHA-1 before the 
> forced push ! 
> Many thanks to Nathan Witmer :-) 
> 
> See below the full CSV with the SHA-1. 
> He created as well a branch named 'recovery' that points to the candidate 
> point for restoring the master branch. 
> 
> Hope this will help to sort out the remaining repos. 
> 
> Luca. 
> 
> > Hi Luca. 
> > 
> > Oh man, that sinking feeling! 
> > 
> > But, no worries: I've gone through each of the repos listed above and done 
> > the following: 
> > 
> > * retrieved the SHA for the previous `master` before you force-pushed 
> > * created a branch called `recovery` pointing to each former master 
> > 
> > In some cases, these are the same. 
> > 
> > I can go further and reset the master refs to their former shas if you'd 
> > like, or you can recover these yourself. To do so, in each repo: 
> > 
> > $ git fetch 
> > $ git checkout master 
> > $ git reset --hard origin/recovery 
> > $ git push --force origin master 
> > 
> > I've attached a csv containing the shas (former master and forced master) 
> > for each branch, for your reference. 
> > 
> > Good luck! 
> > 
> > Nathan.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Looking again at the list right now: there are a few in the same situation :-(

Luca
-
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio


On 12 Nov 2013, at 12:16, Ikedam  wrote:

> Unfortunately, there may be something wrong with this list...
> 
> scoring-load-balancer-plugin have same orig_master and forced_master, 634609e.
> And the version in its pom.xml  is 1.0.1-SNAPSHOT.
> 
> But I have released scoring-load-balancer-1.0.1 last week.
> The latest commit should be:
> https://github.com/jenkinsci/scoring-load-balancer-plugin/commit/0ca553b933521ba82746a491b3c29d8c6cc2ae89
> 
> There may be same problems in other plugins if they are updated in a week.
> 
> 
> On Tuesday, November 12, 2013 7:22:55 AM UTC+9, lucamilanesio wrote:
>> 
>> Good news from GitHub: they have extracted the full list of SHA-1 before the 
>> forced push ! 
>> Many thanks to Nathan Witmer :-) 
>> 
>> See below the full CSV with the SHA-1. 
>> He created as well a branch named 'recovery' that points to the candidate 
>> point for restoring the master branch. 
>> 
>> Hope this will help to sort out the remaining repos. 
>> 
>> Luca. 
>> 
>> > Hi Luca. 
>> > 
>> > Oh man, that sinking feeling! 
>> > 
>> > But, no worries: I've gone through each of the repos listed above and done 
>> > the following: 
>> > 
>> > * retrieved the SHA for the previous `master` before you force-pushed 
>> > * created a branch called `recovery` pointing to each former master 
>> > 
>> > In some cases, these are the same. 
>> > 
>> > I can go further and reset the master refs to their former shas if you'd 
>> > like, or you can recover these yourself. To do so, in each repo: 
>> > 
>> > $ git fetch 
>> > $ git checkout master 
>> > $ git reset --hard origin/recovery 
>> > $ git push --force origin master 
>> > 
>> > I've attached a csv containing the shas (former master and forced master) 
>> > for each branch, for your reference. 
>> > 
>> > Good luck! 
>> > 
>> > Nathan.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Commit loss prevention

[Luca Milanesio]

Seems a very good idea, it is basically a remote audit trail.

The only concern is the throttling on the GitHub API: it would be better then 
to do the scripting on a local mirror of the GitHub repos. When you receive a 
forced update you do have anyway all the previous commits and the full reflog.

However as you said by being triggered via web hook the number of API calls can 
be reduced to the minimum.

I would submit a proposal to the Git mailing list of a "fetch by SHA1" which is 
a missing feature in Git IMHO.

Thanks to everyone including GitHub for the help and cooperation in getting 
this sorted out !!

Luca
-
Sent from my iPhone
Luca Milanesio
Skype: lucamilanesio


On 12 Nov 2013, at 06:25, Kohsuke Kawaguchi  wrote:

> Now that the commits have been recovered and things are almost back to 
> normal, I think it's time to think about how to prevent this kind of 
> incidents in the future.
> 
> Our open commit access policy was partly made possible by the idea that any 
> bad commits can be always rolled back. But where I failed to think through 
> was that the changes to refs aren't by themselves version controlled, and so 
> it is possible to lose commits by incorrect ref manipulation, such as "git 
> push -f", or by deleting a branch.
> 
> I still feel strongly that we maintain the open commit access policy. This is 
> how we've been operating for the longest time, and it's also because 
> otherwise adding/removing developers to repositories would be prohibitively 
> tedious.
> 
> So my proposal is to write a little program that uses GitHub events API to 
> keep track of push activities in our repositories. For every update to a ref 
> in the repository, we can record the timestamp, SHA1 before and after, the 
> user ID. We can maintain a text file for every ref in every repository, and 
> the program can append lines to it. In other words, effectively recreate 
> server-side reflog outside GitHub.
> 
> The program should also fetch commits, so that it has a local copy for every 
> commit that ever landed on our repositories. Doing this also allows the 
> program to detect non fast-forward. It should warn us in that situation, plus 
> it will create a ref on the commit locally to prevent it from getting lost.
> 
> We can then make these repositories accessible via rsync to encourage people 
> to mirror them for backup, or we can make them publicly accessible by hosting 
> them on GitHub as well, although the latter could be confusing.
> 
> WIth a scheme like this, pushes can be safely recorded within a minute or so 
> (and this number can go down even further if we use webhooks.) If a data loss 
> occurs before the program gets to record newly pushed commits, we should 
> still be able to record who pushed afterward to identify who has the commits 
> that were lost. With such a small time window between the push and the 
> record, the number of such lost commits should be low enough such that we can 
> recover them manually.
> 
> -- 
> 
> Kohsuke Kawaguchi
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Good news from GitHub: they have extracted the full list of SHA-1 before the 
forced push !
Many thanks to Nathan Witmer :-)

See below the full CSV with the SHA-1.
He created as well a branch named 'recovery' that points to the candidate point 
for restoring the master branch.

Hope this will help to sort out the remaining repos.

Luca.

> Hi Luca.
> 
> Oh man, that sinking feeling!
> 
> But, no worries: I've gone through each of the repos listed above and done 
> the following: 
> 
> * retrieved the SHA for the previous `master` before you force-pushed
> * created a branch called `recovery` pointing to each former master
> 
> In some cases, these are the same.
> 
> I can go further and reset the master refs to their former shas if you'd 
> like, or you can recover these yourself. To do so, in each repo:
> 
> $ git fetch
> $ git checkout master
> $ git reset --hard origin/recovery
> $ git push --force origin master
> 
> I've attached a csv containing the shas (former master and forced master) for 
> each branch, for your reference.
> 
> Good luck!
> 
> Nathan.

On 11 Nov 2013, at 22:08, Kohsuke Kawaguchi  wrote:

> On 11/11/2013 12:23 PM, Kohsuke Kawaguchi wrote:
>> 
>> Yes, I was thinking about the same. The last run of this is Nov 9,
>> 11:24pm in EST.
>> 
>> I really hope this is before the incident. But I'll find out soon.
> 
> Unfortunately, it appears that the last sync process has run after luca's 
> "push -f".
> 
> I'll hold on to this repo just in case, but resurrecting lost commits from 
> this appears hopeless.
> 
>> 
>> On 11/11/2013 12:15 AM, Vojtech Juranek wrote:
>>> On Sunday 10 November 2013 21:40:28 Luca Milanesio wrote:
>>>> That's really pitty :-( ... force push are dangerous, especially if you
>>>> don't have control over the Git Server.
>>> 
>>> I wonder if we can use our all.git [1] somehow (in the worst case scenario
>>> that github doesn't help us). When it try to clone it, it fails with remote
>>> error and when looking into web UI the changes are already synchronized with
>>> github. But IMHO still worth to investigate, orphan commits could still be
>>> there
>>> 
>>> [1] http://git.jenkins-ci.org/?p=all.git;a=summary
>>> 
>> 
>> 
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

repo,orig_master,forced_master
antexec-plugin,a26ab90,3f8b343
artifactory-plugin,7b6d785,7b6d785
associated-files-plugin,fc7bbc9,e2ada55
audit2db-plugin,faf3385,6b2446b
audit-trail-plugin,105373b,e6b3357
backend-pull-request-greeter,a1f7b15,c5087d6
beaker-builder-plugin,2faad6c,2867a2a
branch-api-plugin,c066281,c066281
build-flow-plugin,4461ead,305af7f
buildgraph-view,4a6eb7f,467286f
build-pipeline-plugin,220610b,64db20c
build-timeout-plugin,437818e,437818e
buildtriggerbadge-plugin,0ecad1e,4f33890
bytecode-compatibility-transformer,9884d93,a62e389
ci-game-plugin,c662016,c662016
clearcase-plugin,4c8e9aa,4c8e9aa
clearcase-ucm-plugin,6be8eec,6be8eec
cloudbees-folder-plugin,f36d4d6,2af4a8b
cloudbees-plugin-gateway,07c9076,f8b6301
cloudtest-plugin,4168346,5627e28
clover-plugin,a9861ae,b590403
cobertura-plugin,bac4f17,d04c87d
collabnet-plugin,18a6109,18a6109
collapsing-console-sections-plugin,53a55ff,53a55ff
compact-columns-plugin,7c68839,a303a24
compress-artifacts-plugin,24d43d2,24d43d2
conditional-buildstep-plugin,ea9246c,4e34efc
config-file-provider-plugin,7ecd9f9,b926025
configurationslicing-plugin,ded8666,eefdd37
copyartifact-plugin,dc98ffe,46540cc
copy-project-link-plugin,6cfffe4,6cfffe4
copy-to-slave-plugin,6ebdccd,6ebdccd
cppcheck-plugin,d018417,5b6922c
credentials-plugin,4a1900a,4a1900a
crowd2-plugin,62ae57b,62ae57b
crowd-plugin,0c4cc5e,0c4cc5e
customtools-plugin,99eaa76,4128bbe
cvsclient,c16ac7b,3003bc9
cvs-plugin,eb2a491,78bb5fb
dashboard-view-plugin,dbcf1ac,48c29c6
datical-db-plugin,a007da0,d08d54e
dependency-check-plugin,5254918,eba7b2e
deploy-plugin,1e0a0fa,a9add4e
disable-failed-job-plugin,3dfe450,3dfe450
disk-usage-plugin,3321172,8f6300d
doclinks-plugin,3369f4c,88a9894
dry-plugin,2dbb3ca,733175d
dynamic-axis-plugin,2ff9d59,56a25ad
ec2-plugin,b14ebd2,b14ebd2
elastic-axis-plugin,19ce48a,2a9a0a3
email-ext-plugin,b7edb86,b7edb86
envinject-lib,4261bc7,c953dae
envinject-plugin,0287bec,afc2f6b
extended-choice-parameter-plugin,8

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Yes, I think that would be a sensible approach.
As some of the people started already to push their up-to-date repo, it is 
better a push from the CI node rather than a "reset" from the GitHub guys at 
this stage.

Luca.

On 11 Nov 2013, at 10:38, nicolas de loof  wrote:

> I can look into this while traveling to devoxx tomorrow
> 
> 
> 2013/11/11 Arnaud Héritier 
> Hi Nicolas. 
> 
>   For me it would be the safer issue. You could wait for tomorrow (it's a day 
> off today in France) but we just need to take care to not loose these 
> repositories. 
> —
> Sent from Mailbox for iPhone
> 
> 
> On Mon, Nov 11, 2013 at 11:25 AM, nicolas de loof  
> wrote:
> in worst case, we have a clone on jenkins.ci.cloudbees.com we can use to push 
> back to github.
> just need some scripting to use it.
> 
> would you like me to look into this option ?
> 
> 
> 2013/11/11 Mads Nielsen 
> What is the recommended way to get a full restore, in the case where you do 
> not happen to have a local clone of the repository which was cloned before 
> the accident?
> 
> 
> On Sun, Nov 10, 2013 at 7:55 PM, Luca Milanesio  
> wrote:
> Hi all,
> I have triggered an involuntary "forced push" last night on the list of 
> Jenkins-CI plugins indicated below in this e-mail.
> 
> My apology 
> 
> I did not realise that I actually had forced push permissions and I do 
> apologise for the inconvenience caused.
> The operations pushed back the all the branches to around 1 month. The 
> history is not lost and is still on the GitHub server but on detached 
> branches.
> 
> The solution
> 
> I can raise a request to GitHub to provide the "reflog" of those repositories 
> and restore the branches to the point before my forced push.
> Alternatively the owners of those repositories can still perform a "forced 
> push" to restore the correct position of the branches.
> (if you would like to do so, please write to the mailing list so that we do 
> not overlap the recovery operations)
> 
> The full list
> 
> See below the full list of repositories impacted:
> 
> antexec-plugin.git
> artifactory-plugin.git
> associated-files-plugin.git
> audit2db-plugin.git
> audit-trail-plugin.git
> backend-pull-request-greeter.git
> beaker-builder-plugin.git
> branch-api-plugin.git
> build-flow-plugin.git
> buildgraph-view.git
> build-pipeline-plugin.git
> build-timeout-plugin.git
> buildtriggerbadge-plugin.git
> bytecode-compatibility-transformer.git
> ci-game-plugin.git
> clearcase-plugin.git
> clearcase-ucm-plugin.git
> cloudbees-folder-plugin.git
> cloudbees-plugin-gateway.git
> cloudtest-plugin.git
> clover-plugin.git
> cobertura-plugin.git
> collabnet-plugin.git
> collapsing-console-sections-plugin.git
> compact-columns-plugin.git
> compress-artifacts-plugin.git
> conditional-buildstep-plugin.git
> config-file-provider-plugin.git
> configurationslicing-plugin.git
> copyartifact-plugin.git
> copy-project-link-plugin.git
> copy-to-slave-plugin.git
> cppcheck-plugin.git
> credentials-plugin.git
> crowd2-plugin.git
> crowd-plugin.git
> customtools-plugin.git
> cvsclient.git
> cvs-plugin.git
> dashboard-view-plugin.git
> datical-db-plugin.git
> dependency-check-plugin.git
> deploy-plugin.git
> disable-failed-job-plugin.git
> disk-usage-plugin.git
> doclinks-plugin.git
> dry-plugin.git
> dynamic-axis-plugin.git
> ec2-plugin.git
> elastic-axis-plugin.git
> email-ext-plugin.git
> envinject-lib.git
> envinject-plugin.git
> extended-choice-parameter-plugin.git
> extra-columns-plugin.git
> extras-executable-war.git
> extreme-feedback-plugin.git
> gearman-plugin.git
> gerrit-trigger-plugin.git
> gitbucket-plugin.git
> git-chooser-alternative-plugin.git
> git-client-plugin.git
> git-plugin.git
> global-build-stats-plugin.git
> global-variable-string-parameter-plugin.git
> gradle-jpi-plugin.git
> grails-plugin.git
> greenballs-plugin.git
> groovy-postbuild-plugin.git
> heavy-job-plugin.git
> hockeyapp-plugin.git
> http-request-plugin.git
> humbug-plugin.git
> instant-messaging-plugin.git
> integrity-plugin.git
> ironmq-notifier-plugin.git
> ivytrigger-plugin.git
> jacoco-plugin.git
> jclouds-plugin.git
> jira-plugin.git
> jobConfigHistory-plugin.git
> job-dsl-plugin.git
> job-import-plugin.git
> job-poll-action-plugin.git
> jquery-plugin.git
> jquery-ui-plugin.git
> json-lib.git
> kiuwan-plugin.git
> label-verifier-plugin.git
> ldap-plugin.git
> leiningen-plugin.git
> lib-annotation-indexer.git
> lib-task-reactor.git
> lib-windows-remote-command.git
> literate-cli.git
> logfilesizeche

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Does anyone have news from GitHub ?
They haven't responded at all to my customer support request :-(

Luca.

On 10 Nov 2013, at 23:42, Christopher Orr  wrote:

> On 11/11/2013 12:24 AM, Luca Milanesio wrote:
>>> BTW, out of curiosity, how did you manage to force push such a large
>>> number of repositories at the same time? :)
>> 
>> Problems with the Gerrit replication plugin ... unfortunate combination
>> of three events (Murphy's law ?):
>> - working on a directory where I had the Jenkins plugins repos cloned
>> (but outdated to around 1 month ago)
>> - having a Gerrit replication plugin pointing to that directory (I did
>> not realised was using *forced push* that until later today)
>> - having the permissions of making *forced push* on repos that I did not
>> work on (I did not realised that until today)
>> 
>> I have removed those local repos on my machine ... so can't do it again,
>> but we need to sort out the mess in the meantime :-(
>> I am submitting now a patch to Gerrit replication plugin to **forbid*
>> forced push by configuration*: so at least I can block them from my side.
> 
> Yeah, that's unlucky.
> 
> One thing I sometimes do for repos where I have commit access, but don't want 
> to push, is to clone the repository via HTTP.  That way, any accidental 
> attempts at pushing won't use my ssh key, and so GitHub will prompt me for my 
> password.
> 
> Regards,
> Chris
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

GitHub model is based on pull requests and not on shared Git repositories: 
that's why protections against forced push is typically not needed (typically 
repo is pushed by only its maintainers and not by contributors).
The way we use GitHub with Jenkins is not very typical for  them :-)

On 10 Nov 2013, at 22:42, Christopher Orr  wrote:

> With 678 members in the jenkinsci organisation, we're probably relatively 
> exceptional; I can't imagine GitHub have much incentive to implement the type 
> of fine-grained force-push permissions we would need.
> 
> Plus I think even with the number of members we have, git accidents are very 
> rare, i.e. it's likely easier to fix mistakes in git, than to maintain a big 
> set of permissions for new and existing users/repos.

Yes they are rare ! ... but when they happen you need to sort them out :-(

> BTW, out of curiosity, how did you manage to force push such a large number 
> of repositories at the same time? :)

Problems with the Gerrit replication plugin ... unfortunate combination of 
three events (Murphy's law ?):
- working on a directory where I had the Jenkins plugins repos cloned (but 
outdated to around 1 month ago)
- having a Gerrit replication plugin pointing to that directory (I did not 
realised was using *forced push* that until later today)
- having the permissions of making *forced push* on repos that I did not work 
on (I did not realised that until today)

I have removed those local repos on my machine ... so can't do it again, but we 
need to sort out the mess in the meantime :-(
I am submitting now a patch to Gerrit replication plugin to *forbid* forced 
push by configuration: so at least I can block them from my side.

Possibly a bit late ... closing the gates when the sheep just escaped ;-(

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

That's really pitty :-( ... force push are dangerous, especially if you don't 
have control over the Git Server.

Typically recovering a force push is straightforward:
1. git reflog > look at the SHA-1 before the forced push
2. git branch -f  

But if you don't have control over the Git repo on the Server, that you need to 
prevent force push to happen: unless they want everyone to buy GH Enterprise !

I still hope GitHub will do 1. and 2. for us :-)

Luca.

On 10 Nov 2013, at 19:52, Marcus Bauer  wrote:

> Hi,
> 
> I don't think GitHub.com has any possibilities for disabling force pushes, 
> this seems to be exclusive to GH Enterprise only.
> 
> The JaCoCo repo where I initially noticed this was restored by Dominik 
> Stadler (centic9) few minutes ago.
> 
> Marcus
> 
> Am Sonntag, 10. November 2013 19:55:08 UTC+1 schrieb lucamilanesio:
> Hi all,
> I have triggered an involuntary "forced push" last night on the list of 
> Jenkins-CI plugins indicated below in this e-mail.
> 
> My apology 
> 
> I did not realise that I actually had forced push permissions and I do 
> apologise for the inconvenience caused.
> The operations pushed back the all the branches to around 1 month. The 
> history is not lost and is still on the GitHub server but on detached 
> branches.
> 
> The solution
> 
> I can raise a request to GitHub to provide the "reflog" of those repositories 
> and restore the branches to the point before my forced push.
> Alternatively the owners of those repositories can still perform a "forced 
> push" to restore the correct position of the branches.
> (if you would like to do so, please write to the mailing list so that we do 
> not overlap the recovery operations)
> 
> The full list
> 
> See below the full list of repositories impacted:
> 
> antexec-plugin.git
> artifactory-plugin.git
> associated-files-plugin.git
> audit2db-plugin.git
> audit-trail-plugin.git
> backend-pull-request-greeter.git
> beaker-builder-plugin.git
> branch-api-plugin.git
> build-flow-plugin.git
> buildgraph-view.git
> build-pipeline-plugin.git
> build-timeout-plugin.git
> buildtriggerbadge-plugin.git
> bytecode-compatibility-transformer.git
> ci-game-plugin.git
> clearcase-plugin.git
> clearcase-ucm-plugin.git
> cloudbees-folder-plugin.git
> cloudbees-plugin-gateway.git
> cloudtest-plugin.git
> clover-plugin.git
> cobertura-plugin.git
> collabnet-plugin.git
> collapsing-console-sections-plugin.git
> compact-columns-plugin.git
> compress-artifacts-plugin.git
> conditional-buildstep-plugin.git
> config-file-provider-plugin.git
> configurationslicing-plugin.git
> copyartifact-plugin.git
> copy-project-link-plugin.git
> copy-to-slave-plugin.git
> cppcheck-plugin.git
> credentials-plugin.git
> crowd2-plugin.git
> crowd-plugin.git
> customtools-plugin.git
> cvsclient.git
> cvs-plugin.git
> dashboard-view-plugin.git
> datical-db-plugin.git
> dependency-check-plugin.git
> deploy-plugin.git
> disable-failed-job-plugin.git
> disk-usage-plugin.git
> doclinks-plugin.git
> dry-plugin.git
> dynamic-axis-plugin.git
> ec2-plugin.git
> elastic-axis-plugin.git
> email-ext-plugin.git
> envinject-lib.git
> envinject-plugin.git
> extended-choice-parameter-plugin.git
> extra-columns-plugin.git
> extras-executable-war.git
> extreme-feedback-plugin.git
> gearman-plugin.git
> gerrit-trigger-plugin.git
> gitbucket-plugin.git
> git-chooser-alternative-plugin.git
> git-client-plugin.git
> git-plugin.git
> global-build-stats-plugin.git
> global-variable-string-parameter-plugin.git
> gradle-jpi-plugin.git
> grails-plugin.git
> greenballs-plugin.git
> groovy-postbuild-plugin.git
> heavy-job-plugin.git
> hockeyapp-plugin.git
> http-request-plugin.git
> humbug-plugin.git
> instant-messaging-plugin.git
> integrity-plugin.git
> ironmq-notifier-plugin.git
> ivytrigger-plugin.git
> jacoco-plugin.git
> jclouds-plugin.git
> jira-plugin.git
> jobConfigHistory-plugin.git
> job-dsl-plugin.git
> job-import-plugin.git
> job-poll-action-plugin.git
> jquery-plugin.git
> jquery-ui-plugin.git
> json-lib.git
> kiuwan-plugin.git
> label-verifier-plugin.git
> ldap-plugin.git
> leiningen-plugin.git
> lib-annotation-indexer.git
> lib-task-reactor.git
> lib-windows-remote-command.git
> literate-cli.git
> logfilesizechecker-plugin.git
> m2release-plugin.git
> m2-repo-reaper-plugin.git
> mailer-plugin.git
> matrix-auth-plugin.git
> maven-hpi-plugin.git
> maven-info-plugin.git
> mercurial-plugin.git
> mesos-plugin.git
> metadata-plugin.git
> mock-security-realm-plugin.git
> msbuild-plugin.git
> naginator-plugin.git
> nerrvana-plugin.git
> nested-view-plugin.git
> next-build-number-plugin.git
> next-executions-plugin.git
> parameterized-trigger-plugin.git
> perforce-plugin.git
> performance-plugin.git
> persona-plugin.git
> pitmutation-plugin.git
> plain-credentials-plugin.git
> plugin-compat-tester.git
> postbuildscript-plugin.git
> promoted-builds-plugin.git
> prqa-plugin.git
> publish-over-cifs-plugin.git
> puppet-jenkins.git
> radiatorview-plugin.git
> rapiddeploy-plugin.git
> 

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Hi Arnaud,
thanks for the understanding :-) I am used to warn other people from doing any 
"forced push" ... and Murphy's law wanted this time happening to me :-(

On 10 Nov 2013, at 19:30, Arnaud Héritier  wrote:

> Thx guys for these details. We are all humans and subject of doing errors. 
> I hope we'll have some help from github but I'm not sure they may spend many 
> time to help us for an error not coming from their side. 

Technically yes, but for the "customer relationship" and because it is an easy 
recovery (git reflog + git branch), they could make some effort to help us out.
JenkinsCI is possibly the largest customer they have worldwide ;-)

> In any case it is recommended to NOT PULL current master branches from these 
> repositories, your local copy may be more up-to-date. If you have a recent 
> hash you can at least try to push them in github under a branch named 
> "master-fix" the time we find the best solution to repare all master 
> repositories. 
> If you commited on these repositories since yesterday verify that you didn't 
> started your work from the wrong old hash. 
> 
> Idea : in our CI server logs we should be able to find the lastest hash of 
> each repo in the related plugin build. After that we have to find how to 
> restore them. It's easy to do it when you have this commit locally but AFAIK 
> it's not if it is only in the remote (you don't get orphelin commits when you 
> clone a repo)

Yes, that's what I thought as well ... but definitely the "git reflog" on 
GitHub server would be more reliable.
The CI workspace (assuming that Git clones are not shallow copies) may have as 
well those commits as well, but again GitHub would be safer and better IMHO.

Luca

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

*UPDATE* after a cross-check I need to add 2 extra repositories to the list:
accurev-plugin
analysis-core-plugin

The total number of impacted repositories should then be: 186

@ALL: is there anyone with direct contact of some GitHub-er ? It would be best 
to resolve the problem *before* the start of the working week on Monday.

Thanks to everyone that contributed to resolve the problem !

Luca.

On 10 Nov 2013, at 19:10, Luca Milanesio  wrote:

> *UPDATE*
> I have just send the request to GitHub support on-line, looping them as well 
> in this e-mail.
> 
> @GitHub Support: please consider this request as a matter of urgency, thank 
> you.
> 
> Luca.
> 
> On 10 Nov 2013, at 18:55, Luca Milanesio  wrote:
> 
>> Hi all,
>> I have triggered an involuntary "forced push" last night on the list of 
>> Jenkins-CI plugins indicated below in this e-mail.
>> 
>> My apology 
>> 
>> I did not realise that I actually had forced push permissions and I do 
>> apologise for the inconvenience caused.
>> The operations pushed back the all the branches to around 1 month. The 
>> history is not lost and is still on the GitHub server but on detached 
>> branches.
>> 
>> The solution
>> 
>> I can raise a request to GitHub to provide the "reflog" of those 
>> repositories and restore the branches to the point before my forced push.
>> Alternatively the owners of those repositories can still perform a "forced 
>> push" to restore the correct position of the branches.
>> (if you would like to do so, please write to the mailing list so that we do 
>> not overlap the recovery operations)
>> 
>> The full list
>> 
>> See below the full list of repositories impacted:
>> 
>> antexec-plugin.git
>> artifactory-plugin.git
>> associated-files-plugin.git
>> audit2db-plugin.git
>> audit-trail-plugin.git
>> backend-pull-request-greeter.git
>> beaker-builder-plugin.git
>> branch-api-plugin.git
>> build-flow-plugin.git
>> buildgraph-view.git
>> build-pipeline-plugin.git
>> build-timeout-plugin.git
>> buildtriggerbadge-plugin.git
>> bytecode-compatibility-transformer.git
>> ci-game-plugin.git
>> clearcase-plugin.git
>> clearcase-ucm-plugin.git
>> cloudbees-folder-plugin.git
>> cloudbees-plugin-gateway.git
>> cloudtest-plugin.git
>> clover-plugin.git
>> cobertura-plugin.git
>> collabnet-plugin.git
>> collapsing-console-sections-plugin.git
>> compact-columns-plugin.git
>> compress-artifacts-plugin.git
>> conditional-buildstep-plugin.git
>> config-file-provider-plugin.git
>> configurationslicing-plugin.git
>> copyartifact-plugin.git
>> copy-project-link-plugin.git
>> copy-to-slave-plugin.git
>> cppcheck-plugin.git
>> credentials-plugin.git
>> crowd2-plugin.git
>> crowd-plugin.git
>> customtools-plugin.git
>> cvsclient.git
>> cvs-plugin.git
>> dashboard-view-plugin.git
>> datical-db-plugin.git
>> dependency-check-plugin.git
>> deploy-plugin.git
>> disable-failed-job-plugin.git
>> disk-usage-plugin.git
>> doclinks-plugin.git
>> dry-plugin.git
>> dynamic-axis-plugin.git
>> ec2-plugin.git
>> elastic-axis-plugin.git
>> email-ext-plugin.git
>> envinject-lib.git
>> envinject-plugin.git
>> extended-choice-parameter-plugin.git
>> extra-columns-plugin.git
>> extras-executable-war.git
>> extreme-feedback-plugin.git
>> gearman-plugin.git
>> gerrit-trigger-plugin.git
>> gitbucket-plugin.git
>> git-chooser-alternative-plugin.git
>> git-client-plugin.git
>> git-plugin.git
>> global-build-stats-plugin.git
>> global-variable-string-parameter-plugin.git
>> gradle-jpi-plugin.git
>> grails-plugin.git
>> greenballs-plugin.git
>> groovy-postbuild-plugin.git
>> heavy-job-plugin.git
>> hockeyapp-plugin.git
>> http-request-plugin.git
>> humbug-plugin.git
>> instant-messaging-plugin.git
>> integrity-plugin.git
>> ironmq-notifier-plugin.git
>> ivytrigger-plugin.git
>> jacoco-plugin.git
>> jclouds-plugin.git
>> jira-plugin.git
>> jobConfigHistory-plugin.git
>> job-dsl-plugin.git
>> job-import-plugin.git
>> job-poll-action-plugin.git
>> jquery-plugin.git
>> jquery-ui-plugin.git
>> json-lib.git
>> kiuwan-plugin.git
>> label-verifier-plugin.git
>> ldap-plugin.git
>> leiningen-plugin.git
>> lib-annotation-indexer.git
>> lib-task-reactor.git
>> lib-windows-remote-command.git
>> literate-cli.git
>> 

Re: AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

*UPDATE*
I have just send the request to GitHub support on-line, looping them as well in 
this e-mail.

@GitHub Support: please consider this request as a matter of urgency, thank you.

Luca.

On 10 Nov 2013, at 18:55, Luca Milanesio  wrote:

> Hi all,
> I have triggered an involuntary "forced push" last night on the list of 
> Jenkins-CI plugins indicated below in this e-mail.
> 
> My apology 
> 
> I did not realise that I actually had forced push permissions and I do 
> apologise for the inconvenience caused.
> The operations pushed back the all the branches to around 1 month. The 
> history is not lost and is still on the GitHub server but on detached 
> branches.
> 
> The solution
> 
> I can raise a request to GitHub to provide the "reflog" of those repositories 
> and restore the branches to the point before my forced push.
> Alternatively the owners of those repositories can still perform a "forced 
> push" to restore the correct position of the branches.
> (if you would like to do so, please write to the mailing list so that we do 
> not overlap the recovery operations)
> 
> The full list
> 
> See below the full list of repositories impacted:
> 
> antexec-plugin.git
> artifactory-plugin.git
> associated-files-plugin.git
> audit2db-plugin.git
> audit-trail-plugin.git
> backend-pull-request-greeter.git
> beaker-builder-plugin.git
> branch-api-plugin.git
> build-flow-plugin.git
> buildgraph-view.git
> build-pipeline-plugin.git
> build-timeout-plugin.git
> buildtriggerbadge-plugin.git
> bytecode-compatibility-transformer.git
> ci-game-plugin.git
> clearcase-plugin.git
> clearcase-ucm-plugin.git
> cloudbees-folder-plugin.git
> cloudbees-plugin-gateway.git
> cloudtest-plugin.git
> clover-plugin.git
> cobertura-plugin.git
> collabnet-plugin.git
> collapsing-console-sections-plugin.git
> compact-columns-plugin.git
> compress-artifacts-plugin.git
> conditional-buildstep-plugin.git
> config-file-provider-plugin.git
> configurationslicing-plugin.git
> copyartifact-plugin.git
> copy-project-link-plugin.git
> copy-to-slave-plugin.git
> cppcheck-plugin.git
> credentials-plugin.git
> crowd2-plugin.git
> crowd-plugin.git
> customtools-plugin.git
> cvsclient.git
> cvs-plugin.git
> dashboard-view-plugin.git
> datical-db-plugin.git
> dependency-check-plugin.git
> deploy-plugin.git
> disable-failed-job-plugin.git
> disk-usage-plugin.git
> doclinks-plugin.git
> dry-plugin.git
> dynamic-axis-plugin.git
> ec2-plugin.git
> elastic-axis-plugin.git
> email-ext-plugin.git
> envinject-lib.git
> envinject-plugin.git
> extended-choice-parameter-plugin.git
> extra-columns-plugin.git
> extras-executable-war.git
> extreme-feedback-plugin.git
> gearman-plugin.git
> gerrit-trigger-plugin.git
> gitbucket-plugin.git
> git-chooser-alternative-plugin.git
> git-client-plugin.git
> git-plugin.git
> global-build-stats-plugin.git
> global-variable-string-parameter-plugin.git
> gradle-jpi-plugin.git
> grails-plugin.git
> greenballs-plugin.git
> groovy-postbuild-plugin.git
> heavy-job-plugin.git
> hockeyapp-plugin.git
> http-request-plugin.git
> humbug-plugin.git
> instant-messaging-plugin.git
> integrity-plugin.git
> ironmq-notifier-plugin.git
> ivytrigger-plugin.git
> jacoco-plugin.git
> jclouds-plugin.git
> jira-plugin.git
> jobConfigHistory-plugin.git
> job-dsl-plugin.git
> job-import-plugin.git
> job-poll-action-plugin.git
> jquery-plugin.git
> jquery-ui-plugin.git
> json-lib.git
> kiuwan-plugin.git
> label-verifier-plugin.git
> ldap-plugin.git
> leiningen-plugin.git
> lib-annotation-indexer.git
> lib-task-reactor.git
> lib-windows-remote-command.git
> literate-cli.git
> logfilesizechecker-plugin.git
> m2release-plugin.git
> m2-repo-reaper-plugin.git
> mailer-plugin.git
> matrix-auth-plugin.git
> maven-hpi-plugin.git
> maven-info-plugin.git
> mercurial-plugin.git
> mesos-plugin.git
> metadata-plugin.git
> mock-security-realm-plugin.git
> msbuild-plugin.git
> naginator-plugin.git
> nerrvana-plugin.git
> nested-view-plugin.git
> next-build-number-plugin.git
> next-executions-plugin.git
> parameterized-trigger-plugin.git
> perforce-plugin.git
> performance-plugin.git
> persona-plugin.git
> pitmutation-plugin.git
> plain-credentials-plugin.git
> plugin-compat-tester.git
> postbuildscript-plugin.git
> promoted-builds-plugin.git
> prqa-plugin.git
> publish-over-cifs-plugin.git
> puppet-jenkins.git
> radiatorview-plugin.git
> rapiddeploy-plugin.git
> release-plugin.git
> repo-plugin.git
> rich-text-publisher-plugin.git
> robot-plugin.git
> run-condition-

AW - *PLEASE READ* Re: strange pushes on GitHub

[Luca Milanesio]

Hi all,
I have triggered an involuntary "forced push" last night on the list of 
Jenkins-CI plugins indicated below in this e-mail.

My apology 

I did not realise that I actually had forced push permissions and I do 
apologise for the inconvenience caused.
The operations pushed back the all the branches to around 1 month. The history 
is not lost and is still on the GitHub server but on detached branches.

The solution

I can raise a request to GitHub to provide the "reflog" of those repositories 
and restore the branches to the point before my forced push.
Alternatively the owners of those repositories can still perform a "forced 
push" to restore the correct position of the branches.
(if you would like to do so, please write to the mailing list so that we do not 
overlap the recovery operations)

The full list

See below the full list of repositories impacted:

antexec-plugin.git
artifactory-plugin.git
associated-files-plugin.git
audit2db-plugin.git
audit-trail-plugin.git
backend-pull-request-greeter.git
beaker-builder-plugin.git
branch-api-plugin.git
build-flow-plugin.git
buildgraph-view.git
build-pipeline-plugin.git
build-timeout-plugin.git
buildtriggerbadge-plugin.git
bytecode-compatibility-transformer.git
ci-game-plugin.git
clearcase-plugin.git
clearcase-ucm-plugin.git
cloudbees-folder-plugin.git
cloudbees-plugin-gateway.git
cloudtest-plugin.git
clover-plugin.git
cobertura-plugin.git
collabnet-plugin.git
collapsing-console-sections-plugin.git
compact-columns-plugin.git
compress-artifacts-plugin.git
conditional-buildstep-plugin.git
config-file-provider-plugin.git
configurationslicing-plugin.git
copyartifact-plugin.git
copy-project-link-plugin.git
copy-to-slave-plugin.git
cppcheck-plugin.git
credentials-plugin.git
crowd2-plugin.git
crowd-plugin.git
customtools-plugin.git
cvsclient.git
cvs-plugin.git
dashboard-view-plugin.git
datical-db-plugin.git
dependency-check-plugin.git
deploy-plugin.git
disable-failed-job-plugin.git
disk-usage-plugin.git
doclinks-plugin.git
dry-plugin.git
dynamic-axis-plugin.git
ec2-plugin.git
elastic-axis-plugin.git
email-ext-plugin.git
envinject-lib.git
envinject-plugin.git
extended-choice-parameter-plugin.git
extra-columns-plugin.git
extras-executable-war.git
extreme-feedback-plugin.git
gearman-plugin.git
gerrit-trigger-plugin.git
gitbucket-plugin.git
git-chooser-alternative-plugin.git
git-client-plugin.git
git-plugin.git
global-build-stats-plugin.git
global-variable-string-parameter-plugin.git
gradle-jpi-plugin.git
grails-plugin.git
greenballs-plugin.git
groovy-postbuild-plugin.git
heavy-job-plugin.git
hockeyapp-plugin.git
http-request-plugin.git
humbug-plugin.git
instant-messaging-plugin.git
integrity-plugin.git
ironmq-notifier-plugin.git
ivytrigger-plugin.git
jacoco-plugin.git
jclouds-plugin.git
jira-plugin.git
jobConfigHistory-plugin.git
job-dsl-plugin.git
job-import-plugin.git
job-poll-action-plugin.git
jquery-plugin.git
jquery-ui-plugin.git
json-lib.git
kiuwan-plugin.git
label-verifier-plugin.git
ldap-plugin.git
leiningen-plugin.git
lib-annotation-indexer.git
lib-task-reactor.git
lib-windows-remote-command.git
literate-cli.git
logfilesizechecker-plugin.git
m2release-plugin.git
m2-repo-reaper-plugin.git
mailer-plugin.git
matrix-auth-plugin.git
maven-hpi-plugin.git
maven-info-plugin.git
mercurial-plugin.git
mesos-plugin.git
metadata-plugin.git
mock-security-realm-plugin.git
msbuild-plugin.git
naginator-plugin.git
nerrvana-plugin.git
nested-view-plugin.git
next-build-number-plugin.git
next-executions-plugin.git
parameterized-trigger-plugin.git
perforce-plugin.git
performance-plugin.git
persona-plugin.git
pitmutation-plugin.git
plain-credentials-plugin.git
plugin-compat-tester.git
postbuildscript-plugin.git
promoted-builds-plugin.git
prqa-plugin.git
publish-over-cifs-plugin.git
puppet-jenkins.git
radiatorview-plugin.git
rapiddeploy-plugin.git
release-plugin.git
repo-plugin.git
rich-text-publisher-plugin.git
robot-plugin.git
run-condition-plugin.git
rvm-plugin.git
scm2job-plugin.git
scm-api-plugin.git
scoring-load-balancer-plugin.git
script-scm-plugin.git
selenium-axis-plugin.git
selenium-builder-plugin.git
selenium-tests.git
skype-im-plugin.git
skytap-cloud-plugin.git
smartfrog-plugin.git
sms-plugin.git
sounds-plugin.git
ssh-agent-plugin.git
ssh-credentials-plugin.git
sshd-module.git
ssh-slaves-plugin.git
starteam-plugin.git
stashnotifier-plugin.git
subversion-plugin.git
suppress-stack-trace-plugin.git
swarm-plugin.git
synergy_scm-plugin.git
tap-plugin.git
teamconcert-plugin.git
testlink-plugin.git
tfs-plugin.git
thin-backup-plugin.git
throttle-concurrent-builds-plugin.git
tikal-multijob-plugin.git
timestamper-plugin.git
token-macro-plugin.git
transifex-plugin.git
translation-plugin.git
trilead-ssh2.git
unity3d-plugin.git
veracode-scanner-plugin.git
view-job-filters-plugin.git
virtualbox-plugin.git
vsphere-cloud-plugin.git
vstestrunner-plugin.git
walldisplay-plugin.git
warnings-plugin.git
weblogic-deployer-plugin.git
winstone.git
wix-plugin.git
ws-cleanup-plugin.git
xcode-pl

Re: Managing Jenkins changes: GitHub Pull request or Gerrit ? … or BOTH :-)

[Luca Milanesio]

Thanks Kohsuke for your feedback,

I have a list of benefits that I am sharing and reviewing with the Gerrit 
community: once that will be completed I would be happy to set-up a shared 
Webinar with the Jenkins and Gerrit community to showcase what Gerrit can do 
integrated with Jenkins to provide benefits to the project's development.

I would like to anticipate my own "golden rule" for every OpenSource (or not) 
projects: dog-fooding !
As most of the users / companies using Gerrit *do integrate* their process with 
Jenkins, it was kind of natural for me to think about how the Jenkins 
development community itself can benefit from the same workflow :-)

Once the feedback collection from the Gerrit community will be completed, I 
will come back with a candidate date / time for a shared webinar between the 
Gerrit and Jenkins communities together to showcase how the integration works !

Kind Regards.

Luca.


On 29 Oct 2013, at 00:50, Kohsuke Kawaguchi  wrote:

> 
> 
> Thanks for this post.
> 
> I think your bottom line is basically that you've created 
> https://gerrithub.io/ and you think we should be using it.
> 
> I hear a lot of good things about Gerrit, so I think this would be 
> interesting, especially if there's some interest among plugin developers.
> 
> Maybe we could schedule an office hour for this? So that interested folks can 
> ask you how this would benefit us. I for one don't quite understand how this 
> really works?
> 
> 
> 
> 
> 
> (For my uninitiated eyes, I must admit that I'm unclear how this fits with 
> our workflow in this project. I feel like pull requests are providing good 
> enough review mechanism when someone wants his code reviewed, and if anything 
> our problem is that we don't have enough people to review code --- I want 
> people to just go ahead and commit their changes, instead of throwing the 
> stuff over the wall and wait for us to come around via pull requests.
> 
> What I really needed was to be able to just push changes and let Jenkins test 
> it *before* commits land to the repository, which we have already solved via 
> the validated merge in 
> https://jenkins.ci.cloudbees.com/job/core/job/jenkins_main_trunk/)
> 
> 
> 
> 
> On 10/10/2013 02:41 AM, Luca Milanesio wrote:
>> Hi Jenkins developers :-)
>> 
>> I am following up to a couple of discussion threads (one at
>> http://jenkins-ci.361315.n4.nabble.com/Jenkins-GitHub-and-Gerrit-Your-thoughts-td4630207.html
>> and another face-to-face with Kohsuke @Google Mountain View in 2011
>> http://google-opensource.blogspot.co.uk/2011/12/gittogether-2011.html)
>> about using GitHub or Gerrit for Jenkins development.
>> 
>> *We are all happily using GitHub pull requests* *BUT* there are _several
>> concerns on the web_, some of them coming directly from Linus Torvalds
>> on the lack of policy and order around GitHub pull requests:
>> http://www.wired.com/wiredenterprise/2012/05/torvalds_github/
>> 
>> Additionally *GitHub has been quite unreliable recently*, forcing (at
>> least us) to stop or slow down our activity quite often !
>> (just look on how many hints you have by Googling "github outage":
>> https://www.google.com/?q=github+outage)
>> 
>> Let me recap on the concerns of using Gerrit when we discussed with
>> Kohsuke F2F back in 2011 @GitTogether in Mountain View:
>> 
>> _1) Lack of GitHub synchronisation_
>> - Gerrit and GitHub are not very well synchronised in terms of
>> replication: you may end up with a situation where a push is made on
>> both Gerrit and GitHub and then you're stuck with a stale replication
>> conflict
>> 
>> _2) Not "as easy" as GitHub pull requests_
>> - Gerrit is GWT-based and its UX is not as nice and effective as GitHub
>> - More difficult to on-board new members because of the learning curve
>> involved with Gerrit
>> 
>> _3) Lack of visibility compared to GitHub_
>> - Gerrit has no public "Hub site" where people can go and look for
>> public repositories
>> 
>> _4) Lack of RESTFul API_
>> - Gerrit has no well-defined and stable RESTFul API as GitHub: more
>> difficult to integrate with other systems
>> 
>> Now, *_situation in October 2013 is VERY different,_* thanks to:
>> - Gerrit 2.8
>> (https://gerrit.googlesource.com/gerrit/+/refs/heads/master/ReleaseNotes/ReleaseNotes-2.8.txt)
>> - GitHub plugin for Gerrit
>> (https://gerrit.googlesource.com/plugins/github/+/refs/heads/master/README.md)
>> 
>> - The first book on Gerrit Code Review
>> (http://aniszczyk.org/2013/09/23/gerrit-code-review-book/)
>> - The first off

Re: Request for JenkinsMobi repositories on github.com/jenkinsci

[Luca Milanesio]

Hi Kohsuke,
I am polishing now the initial commit of the JenkinsMobi contribution and 
preparing an overview description of the project.

I would be ready hopefully by COW with a fully working build taken from the 
GitHub repository.

Does buildhive.cloudbees.com support Android and iOS builds ?
(otherwise I would not be able to automate the validation of the Android and 
iOS full builds but only the SDK, API and Plugin layers)

Additionally, I have noticed that the GitHub hooks could not be added to the 
projects I am managing: who can do it for me on GitHub ?

My projects are:
jenkinsci/jenkinsmobi*
jenkinsci/assembla-plugin

P.S. Great audience and feedback on the "Mobile Application Lifecycle" at the 
Jenkins User Conference !  Slides are available at 
https://www.slideshare.net/lucamilanesio/juc2013-mobileapplicationlifecycle and 
lots of people are asking for the "Continuous Agile stick" that contains 
Gerrit+Jenkins: I've uploaded the USB Stick image at 
http://gerritforge.com/contagile.vm.zip

Thank you in advance.

Luca.

On 21 Oct 2013, at 14:31, Kohsuke Kawaguchi  wrote:

> On 10/21/2013 08:12 AM, Luca Milanesio wrote:
>> Hi Jenkins developers,
>> from today JenkinsMobi will be completely OpenSource under Apache 2.0 
>> license.
> 
> Wow!
> 
> I'd love to have you do a post on http://jenkins-ci.org/node about this. If 
> you can send me the text I can post it there.
> 
>> 
>> I need the following repositories to be created under the JenkinsCI GitHub 
>> organisation:
>> gerritforge/jenkinsmobi-plugin
>> gerritforge/jenkinsmobi-api
>> gerritforge/jenkinsmobi-android
>> gerritforge/jenkinsmobi-android-sdk
>> gerritforge/jenkinsmobi-ios
> 
> All created. If you are on IRC, we should set you up so that you can create 
> repositories by yourself [1].
> 
>> If you want to know how those parts fits together in the Jenkins-driven 
>> Mobile ALM, watch my talk at the JUC 2013 @Palo Alto:
>> http://www.cloudbees.com/jenkins/juc2013/juc2013-palo-alto-abstracts.cb#LucaMilanesio
>> 
>> Thanks in advance.
>> 
>> Luca.
>> 
> 
> [1] https://wiki.jenkins-ci.org/display/JENKINS/IRC+Bot
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Request for JenkinsMobi repositories on github.com/jenkinsci

[Luca Milanesio]

Hi Jenkins developers,
from today JenkinsMobi will be completely OpenSource under Apache 2.0 license.

I need the following repositories to be created under the JenkinsCI GitHub 
organisation:
gerritforge/jenkinsmobi-plugin
gerritforge/jenkinsmobi-api
gerritforge/jenkinsmobi-android
gerritforge/jenkinsmobi-android-sdk
gerritforge/jenkinsmobi-ios

If you want to know how those parts fits together in the Jenkins-driven Mobile 
ALM, watch my talk at the JUC 2013 @Palo Alto:
http://www.cloudbees.com/jenkins/juc2013/juc2013-palo-alto-abstracts.cb#LucaMilanesio

Thanks in advance.

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Announce] First book on Gerrit Code Review

[Luca Milanesio]

... come early, VEEERY EARLY at the GerritForge table, so that you can have you 
free copy :-)

Will distribute as well FREE Gerrit stickers and FREE USB-Sticks with 
Gerrit+Jenkins VM configured and pre-installed !

Luca.

On 16 Oct 2013, at 12:49, Emanuele Zattin  wrote:

> Hi Luca! I will be there and so will two of my business partners so see you 
> there!
> 
> Emanuele Zattin
> ---
> -I don't have to know an answer. I don't feel frightened by not knowing 
> things; by being lost in a mysterious universe without any purpose — which is 
> the way it really is, as far as I can tell, possibly. It doesn't frighten 
> me.- Richard Feynman
> 
> 
> On Wed, Oct 16, 2013 at 1:44 PM, Luca Milanesio  
> wrote:
> Thanks Alex for that, much appreciated !
> 
> I will give away free complimentary copies of the book to the first 10 
> attendees at the Jenkins User Conference in Palo Alto next week:
> http://www.cloudbees.com/jenkins/juc2013/juc2013-palo-alto-abstracts.cb#LucaMilanesio
> 
> I have decided as well to OpenSource the entire JenkinsMobi platform (see 
> http://jenkins-ci.mobi) and host the contributions on Gerrit Code Review :-)
> 
> Hoping the Gerrit Code Review verb will spread :-)
> (450 attendees and potential Gerrit users at the conference next week !)
> 
> For all the Gerrit frends that will be in the Bay Area next week, it would be 
> nice to organise a Gerrit Meet-up !
> Anyone around ?
> 
> Luca.
> 
> On 16 Oct 2013, at 12:17, "Blewitt, Alex"  wrote:
> 
>> There’s also one that has been published at InfoQ this morning, along with 
>> an interview with Luca:
>>  
>> http://www.infoq.com/articles/learning-gerrit-code-review
>>  
>> Alex
>>  
>> From: repo-disc...@googlegroups.com [mailto:repo-disc...@googlegroups.com] 
>> On Behalf Of lucamilanesio
>> Sent: 16 October 2013 11:50
>> To: repo-disc...@googlegroups.com
>> Cc: Luca Milanesio; Edwin Kempin; Fredrik Luthander
>> Subject: Re: [Announce] First book on Gerrit Code Review
>>  
>> With great pleasure I saw this morning a very nice review made by Dariusz:
>> http://luksza.org/2013/learning-gerrit-code-review-by-luca-milanesio/
>>  
>> Thanks for reading the book and taking the time for reviewing it !
>>  
>> Luca.
>> 
>> On Tuesday, September 3, 2013 5:20:12 PM UTC+1, Dave Borowitz wrote:
>> Congratulations Luca on finishing the book!
>>  
>> 
>> On Mon, Sep 2, 2013 at 9:52 AM, Luca Milanesio  wrote:
>> The first book on Gerrit Code Review is officially on sale from today on 
>> Amazon:
>> http://www.amazon.com/Learning-Gerrit-Code-Review-Milanesio/dp/1783289473
>> 
>> My thanks to Edwin Kempin and Fredrik Luthander for the extensive review and 
>> valuable feedback on the content, and to Sarah Owens for the Diffy logo on 
>> the front-page.
>> 
>> Hoping that will contribute to the success and popularity of Gerrit in the 
>> near future :-)
>> 
>> Luca.
>> 
>> --
>> --
>> To unsubscribe, email repo-discuss...@googlegroups.com
>> More info at http://groups.google.com/group/repo-discuss?hl=en
>> 
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Repo and Gerrit Discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to repo-discuss...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>> -- 
>> -- 
>> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
>> More info at http://groups.google.com/group/repo-discuss?hl=en
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Repo and Gerrit Discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to repo-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Announce] First book on Gerrit Code Review

[Luca Milanesio]

Thanks Alex for that, much appreciated !

I will give away free complimentary copies of the book to the first 10 
attendees at the Jenkins User Conference in Palo Alto next week:
http://www.cloudbees.com/jenkins/juc2013/juc2013-palo-alto-abstracts.cb#LucaMilanesio

I have decided as well to OpenSource the entire JenkinsMobi platform (see 
http://jenkins-ci.mobi) and host the contributions on Gerrit Code Review :-)

Hoping the Gerrit Code Review verb will spread :-)
(450 attendees and potential Gerrit users at the conference next week !)

For all the Gerrit frends that will be in the Bay Area next week, it would be 
nice to organise a Gerrit Meet-up !
Anyone around ?

Luca.

On 16 Oct 2013, at 12:17, "Blewitt, Alex"  wrote:

> There’s also one that has been published at InfoQ this morning, along with an 
> interview with Luca:
>  
> http://www.infoq.com/articles/learning-gerrit-code-review
>  
> Alex
>  
> From: repo-disc...@googlegroups.com [mailto:repo-disc...@googlegroups.com] On 
> Behalf Of lucamilanesio
> Sent: 16 October 2013 11:50
> To: repo-disc...@googlegroups.com
> Cc: Luca Milanesio; Edwin Kempin; Fredrik Luthander
> Subject: Re: [Announce] First book on Gerrit Code Review
>  
> With great pleasure I saw this morning a very nice review made by Dariusz:
> http://luksza.org/2013/learning-gerrit-code-review-by-luca-milanesio/
>  
> Thanks for reading the book and taking the time for reviewing it !
>  
> Luca.
> 
> On Tuesday, September 3, 2013 5:20:12 PM UTC+1, Dave Borowitz wrote:
> Congratulations Luca on finishing the book!
>  
> 
> On Mon, Sep 2, 2013 at 9:52 AM, Luca Milanesio  wrote:
> The first book on Gerrit Code Review is officially on sale from today on 
> Amazon:
> http://www.amazon.com/Learning-Gerrit-Code-Review-Milanesio/dp/1783289473
> 
> My thanks to Edwin Kempin and Fredrik Luthander for the extensive review and 
> valuable feedback on the content, and to Sarah Owens for the Diffy logo on 
> the front-page.
> 
> Hoping that will contribute to the success and popularity of Gerrit in the 
> near future :-)
> 
> Luca.
> 
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
> -- 
> -- 
> To unsubscribe, email repo-discuss+unsubscr...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>  
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to repo-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Managing Jenkins changes: GitHub Pull request or Gerrit ? … or BOTH :-)

[Luca Milanesio]

Hi Jenkins developers :-)

I am following up to a couple of discussion threads (one at 
http://jenkins-ci.361315.n4.nabble.com/Jenkins-GitHub-and-Gerrit-Your-thoughts-td4630207.html
 and another face-to-face with Kohsuke @Google Mountain View in 2011 
http://google-opensource.blogspot.co.uk/2011/12/gittogether-2011.html) about 
using GitHub or Gerrit for Jenkins development.

We are all happily using GitHub pull requests *BUT* there are several concerns 
on the web, some of them coming directly from Linus Torvalds on the lack of 
policy and order around GitHub pull requests:
http://www.wired.com/wiredenterprise/2012/05/torvalds_github/

Additionally GitHub has been quite unreliable recently, forcing (at least us) 
to stop or slow down our activity quite often !
(just look on how many hints you have by Googling "github outage": 
https://www.google.com/?q=github+outage)

Let me recap on the concerns of using Gerrit when we discussed with Kohsuke F2F 
back in 2011 @GitTogether in Mountain View:

1) Lack of GitHub synchronisation
- Gerrit and GitHub are not very well synchronised in terms of replication: you 
may end up with a situation where a push is made on both Gerrit and GitHub and 
then you're stuck with a stale replication conflict

2) Not "as easy" as GitHub pull requests
- Gerrit is GWT-based and its UX is not as nice and effective as GitHub
- More difficult to on-board new members because of the learning curve involved 
with Gerrit

3) Lack of visibility compared to GitHub
- Gerrit has no public "Hub site" where people can go and look for public 
repositories

4) Lack of RESTFul API
- Gerrit has no well-defined and stable RESTFul API as GitHub: more difficult 
to integrate with other systems

Now, situation in October 2013 is VERY different, thanks to:
- Gerrit 2.8 
(https://gerrit.googlesource.com/gerrit/+/refs/heads/master/ReleaseNotes/ReleaseNotes-2.8.txt)
- GitHub plugin for Gerrit 
(https://gerrit.googlesource.com/plugins/github/+/refs/heads/master/README.md) 
- The first book on Gerrit Code Review 
(http://aniszczyk.org/2013/09/23/gerrit-code-review-book/)
- The first official Gerrit "Hub" for public projects (http://gerrithub.io)

With all of those new aspects in mind: do we want to assess / review the 
situation ?

Those new elements are "filling the gaps" of the Gerrit minuses identified 2 
years ago:
1) GitHub plugin allows synchronisation of projects and pull requests between 
GitHub and Gerrit (see a demo of Jenkins pull requests in Gerrit on 
https://review.gerrithub.io)
2) Gerrit UX is getting much easier: the book shows how to get started with 
Gerrit with minimal or no knowledge on Git
3) GerritHub.io is getting traction and allows to use Gerrit and GitHub pull 
requests side-by-side
4) Gerrit 2.8 has a rich and powerful set of RESTFul API 
(https://review.gerrithub.io/Documentation/rest-api.html)

Other "big names" in OpenSource are already using Gerrit *AND* GitHub in 
conjunction with lots of success and pride:
- OpenStack (https://wiki.openstack.org/wiki/Gerrit_Workflow)
- Wikimedia (http://www.mediawiki.org/wiki/Gerrit)
- Typo3 (http://wiki.typo3.org/Gerrit)

Opinions, comments, plus and minuses are more than welcome :-)

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Problems with Buildhive builds of github-api

[Luca Milanesio]

Seems that Buildhive is not able to communicate with GitHub for pulling changes 
and running builds:
https://buildhive.cloudbees.com/job/kohsuke/job/github-api/97/console

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not 
known)
Can someone have a look on the machine ?

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Intellij License Renewal

[Luca Milanesio]

I would like to use IntelliJ for the assembla plugin development:
https://github.com/jenkinsci/assembla-plugin

Additionally more plugins are going to be contributed for integrating with the 
JenkinsMobi platform.
(http://jenkins-ci.mobi)

Thanks.

Luca.

On 5 Aug 2013, at 22:10, Emanuele Zattin  wrote:

> I'd love those keys Kohsuke, both for IDEA and RubyMine if possible.
> 
> My plugins:
>  * Extreme Feedback
>  * PeriodicBackup
>  * GroovyAxis
> 
> BR,
> 
> Emanuele Zattin
> ---
> -I don't have to know an answer. I don't feel frightened by not knowing 
> things; by being lost in a mysterious universe without any purpose — which is 
> the way it really is, as far as I can tell, possibly. It doesn't frighten 
> me.- Richard Feynman
> 
> 
> On Mon, Aug 5, 2013 at 8:12 PM, Kohsuke Kawaguchi  
> wrote:
> 
> I got the new key, so those of you who need it, please let me know (along 
> with what plugins you work on, as a due diligence.)
> 
> 
> On 08/03/2013 07:25 AM, Stefan Wolf wrote:
> Hi,
> 
> the Intellij License for the Jenkins project will expire on August 7. Is the
> renewal already under way?
> 
> Best regards,
> Stefan
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> -- 
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Buildhive and Jenkins.ci misaligned

[Luca Milanesio]

Hi all,
am I the only one having problems with builds that are OK on Buildhive and 
failing on Jenkins.ci ?

https://buildhive.cloudbees.com/job/jenkinsci/job/assembla-plugin/10/
vs
https://jenkins.ci.cloudbees.com/job/plugins/job/assembla-plugin/11/

I guess the problem is with the Jenkins Maven repo ... not defined as the 
default one on jenkins.ci.cloudbees.com.

What is the recommended strategy / workaround in this case ?
Who is managing the two cloudbees instances ?

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANNOUNCE] JenkinsMobi V4 Beta

[Luca Milanesio]

For those who are using JenkinsMobi "on-the-go", we started the Beta program of 
the new V4 platform.

We will be following a new "Mobile ALM" approach (see 
http://www.slideshare.net/lucamilanesio/jenkins-mobileapplicationlifecycletrellocollab-net)
 and new features will be added on a daily basis based on everybody's feedback.

For those who are not familiar yet with JenkinsMobi:
a) It is a Jenkins client on Android and iOS to monitor and control your 
Jenkins CI instance (see 
https://play.google.com/store/apps/details?id=com.lmit.jenkins.android.activity)
b) Allows to quickly inspect build output, tests and contact developers 
"on-the-go" in case of problems
c) Provides start/stop control over your jobs

Additionally the goals of the V4 Beta program (http://jenkins-ci.mobi/#v4beta):
1. More stable client and multiple platforms support (Tablets, WP8 and BB10)
2. Easier configuration
3. Faster and safer, thanks to the SSO and 2-step authentication support
4. Extensibility: similarly to Jenkins plugins, you will be able to extend the 
JenkinsMobi platform with your own plugins.

Specifically on point 4, our goal is to make the JenkinsMobi V4 plugins 
infrastructure OpenSource under Apache 2.0 license ... and allowing more people 
to integrate / extends JenkinsMobi with even more integrations !!

What do you think ? Let us know at 
Twitter: @hudsonmobi
Facebook: https://www.facebook.com/hudsonmobi
Blog: http://jenkinsmobi.me

Feedback is always welcome :-)

Luca.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Announcing Assembla Auth plugin for Jenkins

[Luca Milanesio]

Hi,

we already developed last year an Assembla plug-in for linking the issue 
tracker artifacts: see 
https://wiki.jenkins-ci.org/display/JENKINS/Assembla+plugin

Does it make sense to join efforts and make a single plugin for both ?
(less pain for users to get them aligned)

Luca

-
Sent from my iPhone
Luca Milanesio


On 20 Nov 2012, at 14:03, Titas Norkūnas  wrote:

> Hello everyone,
> 
> We’re glad to announce Assembla Auth plugin to the Jenkins community. This 
> plugin adds a security option to delegate authentication and authorization to 
> Assembla:
> authentication delegated to assembla.com
> authorization delegated to your space in assembla.com
> http basic auth REST API works (with API token instead of password though)
> This is the first plugin that we have been working on, but we are planning on 
> doing more (some are in the works). If you are interested in helping 
> integrate Jenkins with Assembla feel free to drop me a note!
> 
> Read more on our blog - 
> http://blog.assembla.com/assemblablog/tabid/12618/bid/92265/Announcing-Assembla-Auth-Plugin-for-Jenkins.aspx
> 
> Kind Regards,
> 
> Titas Norkūnas
> Lead Developer, Assembla

Re: Jenkins, GitHub and Gerrit: Your thoughts?

[Luca Milanesio]

Hi Lloyd,
I am Gerrit contributor and Jenkins contributor and my company name is 
GerritForge, I think there is nothing wrong with this :-)

Coming back to your points, I do think that GitHub and Gerrit are meant to be 
used in different scenarios and they follow different models.
GitHub: "Integration Manager" (see 
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow)
Gerrit: "Central Repository" with topic-branches review (see 
http://git-scm.com/book/ch3-4.html)

Not necessarily one is better than the other, they are just meant to be used in 
different scenarios.
Jenkins community has decided to use GitHub, nothing wrong with this but I do 
think that an integration with Gerrit would be useful anyway !

I spoke with Kohsuke last year @GitTogether 2011 (he participated as well) and 
we discussed this possible integration as it would be a good thing for both 
projects.
GitHub is widely used by Jenkins committers and I do not think anybody is 
thinking about moving away from it :-)

On your proposals, my feedback is:

> - Don't do GitHub pull requests, e.g. 
> https://github.com/torvalds/linux/pull/17#issuecomment-5654674

Don't think make sense for Jenkins dev: pull requests just work even though I 
would agree with Linus on some points.
(@GitHub should spend more time listening to suggestions / complains and put 
them back in the backlog and subject to public voting) 

> - Creating a daemon that auto-closes GitHub pull requests, as Monty Taylor 
> described to me for OpenStack, "Github does not allow a project to disable 
> pull requests, so we also have a daemon which watches for pull requests in to 
> the projects on github and auto-closes them with a message explaining how to 
> submit changes to gerrit for review."
> https://groups.google.com/d/msg/repo-discuss/rersrCtdEiY/WW7xBYjL_iEJ

I think Kohsuke tried as well to set-up a set of cross-hooks between Gerrit and 
GitHub.

@Kohsuke: did you manage to implement something similar ?

> - Or Creating Gerrit code that automatically imports GitHub pull requests


That could be useful though and developed as Gerrit plug-in, seems cool to me.

Situation could be then:
a) Gerrit manages the code-review
b) Gerrit replication "mirrors" the changes to a GitHub repo
c) People clone the public GitHub repo and then creates pull requests
d) Gerrit plug-in automatically gets pull requests from GitHub and creates 
"Patch-sets" to Gerrit for review

Does it make sense ?

Interesting flow IMHO, a good play to start integrating them.

Further comments are welcome :-)

Luca.

Re: Jenkins, GitHub and Gerrit: Your thoughts?

[Luca Milanesio]

Hi LLoyd,

> 
> As of today (May 31, 2012) I'm not foreseeing significant value proposition 
> nor positive return on investment in using Gerrit (in spite of its features) 
> in lively open source projects and communities such as our Jenkins, 
> especially when GitHub pull requests (distributed/forking) with periodic 
> reminders on this mailing list (centralization/federalization) are working 
> well for us. Of course, I could be missing a piece of a larger puzzle, hence 
> I'm asking you these questions:

I think you are right in the sense you are missing the larger puzzle :-)

There is a lot of sense behind Gerrit and a huge return of investment using it 
with Jenkins.
(see http://www.slideshare.net/lucamilanesio/gerrit-code-review)

It is not just the ability to "trigger a build" but the organisation of the 
topic-review lifecycle. 
IMHO GitHub plug-in is the right place to integrate Jenkins and GitHub whilst 
Gerrit-Trigger has a different scope.

Integration between Gerrit and GitHub would be cool, I proposed that last year 
@GitTogether 2011 to the GitHub guys ... but apparently they were neither 
interested nor excited on Gerrit and code-review.

Luca.