Re: Request to become a maintainer for hockeyapp

[Oleg Nenashev]

Hi,

+1 from me.

The discussion in 
https://groups.google.com/forum/#!topic/jenkinsci-dev/LBSZruW0Lfs/ and 
pings in GitHub provide enough justification to transfer ownership IMHO, 
but let's see what others say

Best regards,
Oleg

On Wednesday, May 9, 2018 at 10:48:31 AM UTC+2, Mez Pahlan wrote:
>
> Hi everyone
>
> I would like to formally request to become a maintainer for the hockeyapp 
> plugin, please.
>
> I have started a PR 
>  and a thread 
> discussion 
>  
> detailing why and my efforts to reach the existing maintainers.
>
> Jenkins Infrastructure idt: mezpahlan
> Github id: mezpahlan
>
> Thanks
>

-- 
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/145d4a42-2bfa-4104-ab63-9626ad20b156%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any plans for the github checks API?

[Steven F]

The checks API looks great, but it seems like there is a disconnect between 
the all-in-one Pipeline of Jenkins and what the checks API expects to be 
working with. The examples in the article show elements such as linting, 
build, static analysis as separate and individually runnable things. In 
Jenkins 2.x Pipeline it feels like bundling these things together is more 
encouraged. While you can break things up a bit, it can become unwieldy 
when you get into things like multibranch building.

There's still a lot of potential for helpful usage of the API, these 
differences are just something that I find interesting when reading about 
software pipeline concepts and applications in abstract.

-- 
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/bb280e5a-d639-4029-8115-9379f10f37cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the Parameterized Remote Trigger Plugin

[Oleg Nenashev]

Hi all,

Cristoph has been pinged on April 20 in this thread.So yes, we can do the 
permission transfer.

I have granted permissions to Kai-Hsiang and Tony. Kai-Hsiang is also a 
default assignee in JIRA now. In order to do a release, you will also need 
to update https://github.com/jenkins-infra/repository-permissions-updater.

Welcome aboard!

Best regards,
Oleg

On Thursday, May 10, 2018 at 8:55:53 AM UTC+2, Kai-Hsiang Chang wrote:
>
> Hi Daniel,
>
> it seems no response from the owner, maybe we can start the process? 
>
>
> Alexander Link於 2018年4月27日星期五 UTC+8下午2時55分19秒寫道：
>>
>> Hi,
>>
>> I collected all open review comments: 
>> https://github.com/sap-production/parameterized-remote-trigger-plugin/issues/20
>> We will check the urgency and process the urgent ones.
>>
>> But in general we are using the plugin productively and never had severe 
>> issues. Minor bugs (recognized in our scenarios) have been fixed.
>> I would also vote for merging this PR first. We already tried to split it 
>> up into single meaningful PRs but this is almost not possible anymore.
>>
>> It seems you will be the maintainer in future, so you have to decide if 
>> the changes are good enough :)
>>
>> Thanks a lot and kind regards,
>> Alex
>>
>> Am Dienstag, 24. April 2018 15:45:22 UTC+2 schrieb Kai-Hsiang Chang:
>>>
>>> Hi Alex, 
>>>
>>> If this version has been tested & run for 2 years in your company, I 
>>> think it's okay to just apply this huge PR and refine the code quality & 
>>> the comments later. 
>>> But this is just my opinion, I'm not the maintainer. 
>>>
>>> 2018-04-24 20:22 GMT+08:00 'Alexander Link' via Jenkins Developers <
>>> jenkin...@googlegroups.com>:
>>>
 Hi Tony,

 We incorporated much of the feedback by Oleg (thanks again for the 
 review!), but yes, I think there are still some unprocessed comments 
 (those 
 without +1 marker). We need to decide how urgent they are - currently we 
 are not working on them due to capacity reasons.

 Nevertheless you need to know we are using this version of the plugin 
 productively on more than hundred (team) Jenkinses in our company. 
 Identified bugs in the last 2 years have been fixed, this most likely 
 includes bugs which are still contained in the current official version of 
 the plugin.

 Kind regards,
 Alex


 Am Dienstag, 24. April 2018 13:45:04 UTC+2 schrieb Tony Noble:
>
> I did spend some time looking at that PR, but it appears as though 
> there is still work to be done on it, or at least, changes requested.
>
> Is that not the case?  I got a little lost trying to figure out what 
> was still to be done.
>
> Tony
>
> On Tue, Apr 24, 2018 at 12:18 PM, 'Alexander Link' via Jenkins 
> Developers  wrote:
>
>> Hi,
>>
>>  
>>
>> as Oleg mentioned we did many changes to this plugin in the last 2 
>> years – in our fork unfortunately, since contribution did not work due 
>> to 
>> missing maintainers.
>>
>> You find *all* changes in our openSource branch: 
>> https://github.com/sap-production/parameterized-remote-trigger-plugin/tree/openSource
>>  
>>
>>  
>>
>> We don’t have enough resources to become maintainers ourselves, but 
>> we are happy to support you with this plugin.
>>
>>  
>>
>> My recommendation would be to decide on this PR first to avoid later 
>> conflicts: 
>> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32 
>>
>>  
>>
>> Kind regards, Alex
>>
>>  
>>
>> PS: Here some additional comments about the Pull Request:
>>
>>
>> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32#issuecomment-373000207
>>  
>>
>>
>> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32#issuecomment-338175831
>>  
>>
>>
>>
>>
>> Am Dienstag, 24. April 2018 10:31:16 UTC+2 schrieb Oleg Nenashev:
>>>
>>> I would like to point out that there is a major work being done on 
>>> Pipeline compatibility in 
>>> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32
>>>  
>>> . It would be great to invite Alejandra Ferreiro Vidal and Alexander 
>>> Link 
>>> to this discussion. Will do that.
>>>
>>> BR, Oleg
>>>
>>> On Monday, April 23, 2018 at 8:13:54 AM UTC+2, Kai-Hsiang Chang 
>>> wrote:

 @Tony, thx for the cc.

 github id: cashlalala
 Jenkins JIRA id: cashlalala

 Tony Noble於 2018年4月20日星期五 UTC+8下午8時41分52秒寫道：
>
> I'll happily co-maintain if required.  There's a PR needing to be 
> merged to make it work with CSRF protection (that I've suggested a 
> minor 
> change to) that really could do with being applied, amongst others.

Backporting for LTS 2.121.1 started

[Oliver Gondža]

Backporting has started and the RC is scheduled for 2018-05-23.

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
Fixed: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.121.1-fixed
Rejected: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.121.1-rejected

--
oliver

--
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/cdfe938c-0c14-c9fa-5cc4-a0c210f514dd%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any plans for the github checks API?

[jxpearce]

I'm not sure how the part about rerunning individual stages would work, but 
I could see rerunning the entire job from your github PR page. We sometimes 
have jobs where there are tests which fail occasionally, or 3rd party 
services are flakey, and in those cases just rerunning the job from github 
would save a step.

The part that might be interesting would be providing detailed information 
about why things failed on the PR page, with a list of actual errors. 
Granted this isn't easy, since there's not a consistent way to report 
errors, but the engineers I work with would *love* that level of 
integration. I would assume each "check" would be a single stage in the 
pipeline, so a routine job might have this set of checks:

   - checkout SCM
   - static checks
   - tests
   - deploy


On Thursday, May 10, 2018 at 2:37:39 AM UTC-7, Steven F wrote:
>
> The checks API looks great, but it seems like there is a disconnect 
> between the all-in-one Pipeline of Jenkins and what the checks API expects 
> to be working with. The examples in the article show elements such as 
> linting, build, static analysis as separate and individually runnable 
> things. In Jenkins 2.x Pipeline it feels like bundling these things 
> together is more encouraged. While you can break things up a bit, it can 
> become unwieldy when you get into things like multibranch building.
>
> There's still a lot of potential for helpful usage of the API, these 
> differences are just something that I find interesting when reading about 
> software pipeline concepts and applications in abstract.
>

-- 
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/1b15d973-093f-4e41-a7be-1bac3ff5e2e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the Parameterized Remote Trigger Plugin

[Kai-Hsiang Chang]

Hi Daniel,

it seems no response from the owner, maybe we can start the process? 


Alexander Link於 2018年4月27日星期五 UTC+8下午2時55分19秒寫道：
>
> Hi,
>
> I collected all open review comments: 
> https://github.com/sap-production/parameterized-remote-trigger-plugin/issues/20
> We will check the urgency and process the urgent ones.
>
> But in general we are using the plugin productively and never had severe 
> issues. Minor bugs (recognized in our scenarios) have been fixed.
> I would also vote for merging this PR first. We already tried to split it 
> up into single meaningful PRs but this is almost not possible anymore.
>
> It seems you will be the maintainer in future, so you have to decide if 
> the changes are good enough :)
>
> Thanks a lot and kind regards,
> Alex
>
> Am Dienstag, 24. April 2018 15:45:22 UTC+2 schrieb Kai-Hsiang Chang:
>>
>> Hi Alex, 
>>
>> If this version has been tested & run for 2 years in your company, I 
>> think it's okay to just apply this huge PR and refine the code quality & 
>> the comments later. 
>> But this is just my opinion, I'm not the maintainer. 
>>
>> 2018-04-24 20:22 GMT+08:00 'Alexander Link' via Jenkins Developers <
>> jenkin...@googlegroups.com>:
>>
>>> Hi Tony,
>>>
>>> We incorporated much of the feedback by Oleg (thanks again for the 
>>> review!), but yes, I think there are still some unprocessed comments (those 
>>> without +1 marker). We need to decide how urgent they are - currently we 
>>> are not working on them due to capacity reasons.
>>>
>>> Nevertheless you need to know we are using this version of the plugin 
>>> productively on more than hundred (team) Jenkinses in our company. 
>>> Identified bugs in the last 2 years have been fixed, this most likely 
>>> includes bugs which are still contained in the current official version of 
>>> the plugin.
>>>
>>> Kind regards,
>>> Alex
>>>
>>>
>>> Am Dienstag, 24. April 2018 13:45:04 UTC+2 schrieb Tony Noble:

 I did spend some time looking at that PR, but it appears as though 
 there is still work to be done on it, or at least, changes requested.

 Is that not the case?  I got a little lost trying to figure out what 
 was still to be done.

 Tony

 On Tue, Apr 24, 2018 at 12:18 PM, 'Alexander Link' via Jenkins 
 Developers  wrote:

> Hi,
>
>  
>
> as Oleg mentioned we did many changes to this plugin in the last 2 
> years – in our fork unfortunately, since contribution did not work due to 
> missing maintainers.
>
> You find *all* changes in our openSource branch: 
> https://github.com/sap-production/parameterized-remote-trigger-plugin/tree/openSource
>  
>
>  
>
> We don’t have enough resources to become maintainers ourselves, but we 
> are happy to support you with this plugin.
>
>  
>
> My recommendation would be to decide on this PR first to avoid later 
> conflicts: 
> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32 
>
>  
>
> Kind regards, Alex
>
>  
>
> PS: Here some additional comments about the Pull Request:
>
>
> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32#issuecomment-373000207
>  
>
>
> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32#issuecomment-338175831
>  
>
>
>
>
> Am Dienstag, 24. April 2018 10:31:16 UTC+2 schrieb Oleg Nenashev:
>>
>> I would like to point out that there is a major work being done on 
>> Pipeline compatibility in 
>> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32 
>> . It would be great to invite Alejandra Ferreiro Vidal and Alexander 
>> Link 
>> to this discussion. Will do that.
>>
>> BR, Oleg
>>
>> On Monday, April 23, 2018 at 8:13:54 AM UTC+2, Kai-Hsiang Chang wrote:
>>>
>>> @Tony, thx for the cc.
>>>
>>> github id: cashlalala
>>> Jenkins JIRA id: cashlalala
>>>
>>> Tony Noble於 2018年4月20日星期五 UTC+8下午8時41分52秒寫道：

 I'll happily co-maintain if required.  There's a PR needing to be 
 merged to make it work with CSRF protection (that I've suggested a 
 minor 
 change to) that really could do with being applied, amongst others.

 Christoph shows as last person to make any git commits, so I've 
 cc'd him.

 Tony

 github id: TonyNoble
 Jenkins JIRA id: stealthdj

 On Fri, Apr 20, 2018 at 9:11 AM, Daniel Beck  
 wrote:

>
> > On 20. Apr 2018, at 03:51, Kai-Hsiang Chang  
> wrote:
> > 
> > this plugin hasn't been updated for at least 2 years, 
> > 
> > I'd like to ask the permission to maintain the plugin.
> > 
> > please help 

Re: Any plans for the github checks API?

[Jesse Glick]

On Thu, May 10, 2018 at 5:37 AM, Steven F  wrote:
> The examples in the article show elements such as linting,
> build, static analysis as separate and individually runnable things. In
> Jenkins 2.x Pipeline it feels like bundling these things together is more
> encouraged.

Well, it is generally more straightforward to have those things be run
as part of a single Jenkins build, triggered by SCM changes. What is
missing is an API which would allow Jenkins report plugins (`Publisher
& SimpleBuildStep`, for example) to indicate to the system that there
is some information to be displayed in an abstract “change request”,
perhaps associated with source code lines, which would then be
implemented by `github-branch-source` with the Checks API.

jxpea...@godaddy.com wrote:
> just rerunning the job from github would save a step

See JENKINS-45455 for rerunning generally; again we would need a new
API to allow this is to be integrated with in-PR “chatops” triggers,
so that `github-branch-source` could receive GH events and refire them
as requests to rerun parts of a build, which
`pipeline-model-definition` would then interpret as a Declarative
build trigger.

All this would allow you to do more from GitHub and less from Blue
Ocean or the Jenkins “classic” UI. @abayer has done the most work in
this area and should probably be commenting.

-- 
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/CANfRfr0MNg5_9DFrFKnp%3Darrn06rkZTP-DzW%2BuwcVamF-TRSFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Essentials] Error Telemetry Server API JEP Draft

[R. Tyler Croy]

(replies inline)

On Tue, 08 May 2018, Baptiste Mathus wrote:

> Hello everyone,
> 
> After defining how we would do the client side of error telemetry logging
> in JEP-304 , I just
> published a draft of the corresponding server side for review:
> 
> https://github.com/batmat/jep/tree/JENKINS-51140/


Woohoo more designs! :)

I have a lot of questions and feedback, and since this is an early stage
design, I thiink it would be more efficient for us to jump on a Google Hangout
tomorrow (Friday).

The biggest gap which I'm sure you've thought about but isn't present in this
design document are the client/server interactions and what are the expected
REST calls/responses. Take a look at this for more of what I'm expecting:
https://github.com/jenkinsci/jep/tree/master/jep/303#specification


Cheers

-- 
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/20180510225420.GG2935%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Suggestion: versioning the schema for Configuration as Code

[R. Tyler Croy]

I was thinking about this last week when I was working with Configuration as
Code[0] and thinking about some of the concerns which I've seen voiced about
the "right API for 1.0", especially around Credentials and some other
(currently) gnarly syntax use-cases.

As a user of docker-compose, I find their approach for handling
the changes of their docker-compose.yml format to be quite elegant[1]. They
include a `version: 3` key at the root level of the YAML and then make it
clear in their documentation which versions of docker-compose can make use of
which versions of their schema.

I think this could be helpful for avoiding concerns about the "finality" of a
1.0 release. If the syntax needs to change in the future, just creating a
schema version 2, which can be consumed from a 1.1, or 1.2 release of plugin
would be very reasonable IMHO.



Thought I would share the idea.




[0] https://github.com/jenkinsci/configuration-as-code-plugin
[1] https://docs.docker.com/compose/compose-file/compose-versioning/

-- 
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/20180510201923.GF2935%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Suggestion: versioning the schema for Configuration as Code

[Jesse Glick]

I had the same comment about Declarative Pipeline before it went
1.0—that every script should start with

pipeline(1) {

But to no avail. :-(

-- 
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/CANfRfr1ARV%2Br1u98umpjCZBvd2%3Dh7msQ1TQFTUvbhpoGPc%3Dz6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.