Re: [Plugin adoption] groovy-events-listener-plugin

[marky . r . jackson]

I wanted to circle back on this request. 

-- 
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/c0c0271f-6508-4ae4-9d36-9615a78ec8fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What resources is Cloudbees allocating to Blue Ocean maintenance/development?

[Ullrich Hafner]

Thanks Kohsuke and Jenn for describing the plans for Blue Ocean.

While I understand, that you all are moving away from long-lived road maps I 
think it still would make sense if you would clarify your vision for Blue Ocean 
and Jenkins (and the classic UI) in more detail. 

Blue Ocean started three years ago with the vision to replace the whole UI, 
i.e. jenkins/job/pipeline configuration *and* the visualization of the job 
results. While I think we have a lot of exciting results for the former part 
(and JCaC for the configuratuion), the latter part has only results for less 
than 1% of the plugins. In "Jenkins: Shifting Gears“ Kohsuke also mentioned 
that the next development version of Jenkins will have no UI at all. This makes 
me somewhat uncertain about the future of the UI part in Jenkins. Are there 
still plans to replace the visualization of the job results of all plugins with 
Blue Ocean? Or wouldn’t it be easier to rework the classic UI by letting 
plugins use the old-style jelly model with some modern JS libraries like 
Bootstrap, JQuery, Datatables, ECharts, etc? Or thinking one step further: 
should we forget the Jenkins job visualization UI at all and plugin authors 
should create their own stand-alone UI (e.g. using a simple Spring Boot 
application) and read all information from the pluggable storage of a UI-less 
Jenkins using REST services? 

> Am 11.01.2019 um 19:04 schrieb Ryan :
> 
> I'm a big fan of Blue Ocean as well.  I'd love to see more investment from 
> CouldBees to pushing Blue Ocean to it's limits.  Glad to hear CloudBees is 
> still thinking about it.
> 
> On Wednesday, December 12, 2018 at 3:30:10 PM UTC-5, Craig Rodrigues wrote:
> Hi,
> 
> When BlueOcean was originally being developed, James Dumay,
> who was a Director, Product Management at Cloudbees
> was very active in leading Blue Ocean, and communicating status and
> milestones with the Jenkins community.
> 
> Since James has left Cloudbees, what I have observed is:
> 
> 1.  No one at the manager/director level is visible on the 
> https://gitter.im/jenkinsci/blueocean-plugin 
>  Gitter channel to communicate 
> with users or get feedback
> 2.  Many bugs filed against Blue Ocean in JIRA are unassigned
> 3.  Cloudbees employees who log into 
> https://gitter.im/jenkinsci/blueocean-plugin 
>  seem to be doing so as a 
> best-effort/volunteer level.  For example, on Nov. 16, Keith Zantow reported:
> 
> Keith Zantow @kzantow Nov 16 06:36 @rodrigc hard to say exactly what's in the 
> road map at this moment, but certainly open to patches
> 
> Can someone in Cloudbees management comment on the company's commitment to 
> Blue Ocean?
> 
> I try to do what I can.  I've submitted one bugfix:
> https://github.com/jenkinsci/blueocean-plugin/pull/1794 
> 
> 
> And submitted a few bug reports:
> https://bit.ly/2B8MmmQ 
> 
> Blue Ocean is very good, but needs some bugfixes and usability
> fixes to meet parity with the Jenkins Classic UI.
> Blue Ocean is some complicated "modern JavaScript", and I don't
> have enough time to dig into it to fix the problems myself.
> 
> I am trying to push Blue Ocean and Pipeline very heavily at the companies
> I work for, and for the most part everyone I talk to really likes Blue Ocean,
> but the bugs/gaps are a problem for wider adoption/success in the projects
> I work on.
> 
> Thanks for any feedback.
> 
> --
> Craig
> 
> 
> 
> -- 
> 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/f10ccbbe-41ff-483f-a54d-bdebf2908670%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/5D2BC7B4-E303-4F9D-B127-092A76AF70A5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[Marky Jackson]

I’ve done some current operator work and have submitted an upcoming talk on 
operators. 
I would love to even just tinker with this idea

{ 
   "regards" : {
"name" : “marky”,
"phone" : "+1 (408) 464 2965”,
"email" : “marky.r.jack...@gmail.com",
"team" : "jackson5“
}
}

> On Jan 15, 2019, at 8:38 AM, Jesse Glick  wrote:
> 
>> On Tue, Jan 15, 2019 at 7:56 AM 夏润泽  wrote:
>> we could use the k8s jenkins operator to do more things, such as the health 
>> status of jenkins (whether the configuration is consistent and the necessary 
>> components are normal)、 automatic update based on Jenkins Evergreen…
> 
> There is nothing being done in this area currently. Sounds like a
> sensible addition to
> 
> https://jenkins.io/sigs/cloud-native/#areas-for-improvement
> 
> -- 
> 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/CANfRfr24Y6Vpq2YnUXT3BubDuuzpTXmw-fCgoeeVpM0PTMx%3Dsw%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/BA076E0F-B247-4118-B930-A36CF4A46297%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[Jesse Glick]

On Tue, Jan 15, 2019 at 7:56 AM 夏润泽  wrote:
> we could use the k8s jenkins operator to do more things, such as the health 
> status of jenkins (whether the configuration is consistent and the necessary 
> components are normal)、 automatic update based on Jenkins Evergreen…

There is nothing being done in this area currently. Sounds like a
sensible addition to

https://jenkins.io/sigs/cloud-native/#areas-for-improvement

-- 
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/CANfRfr24Y6Vpq2YnUXT3BubDuuzpTXmw-fCgoeeVpM0PTMx%3Dsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reading console log of parallel stages

[Jesse Glick]

On Mon, Jan 14, 2019 at 6:34 PM Ullrich Hafner  wrote:
> Which API can I use to read the individual console log information of a 
> parallel stage?

There is not an API exactly for that, but you can use various
techniques in `workflow-api` like `FlowScanner` to get the set of
`FlowNode`s in the branch, and you can use `LogAction` (if present) to
retrieve any log text associated with that node.

I think I mentioned at some point that a simpler and more efficient
way to process log messages is to use a block-scoped step, which can
then contextualize a `ConsoleLogFilter` (freestyle-compatible but
clunky) or `TaskListenerDecorator` (Pipeline-specific but cleaner)
that passes through log lines after tallying them for warnings or
whatever, with no need to ever read the build log later.

-- 
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/CANfRfr1F11wKsJtfsUWy4h3ErgvxmyM4BQVrY-gGNZtb9WwgQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[夏润泽]

Jenkins of serverless cannot meet my needs at present, but I have to say 
that when it becomes more perfect, it will be a very cool features.

On Tuesday, January 15, 2019 at 4:17:19 PM UTC+8, Carlos Sanchez wrote:
>
> I thought about it, and yes it would be interesting to have an operator 
> that watches a configmap and ensures jenkins is always updated.
> However with serverless jenkins[1] you wouldn't need to worry about that 
> anymore (if you can use serverless).
>
>
> [1] 
> https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870 
> 
>
> On Tue, Jan 15, 2019 at 6:37 AM 夏润泽 > 
> wrote:
>
>> Hi dev:
>>In the cloud native domain, kubernetes is an important part, and now 
>> many software are using kubernetes operator to manage applications in 
>> kubernetes.
>>Now we can manage jenkins through groovy scripts, casc plugins, etc.In 
>> particular, the casc plugin allows us to manage jenkins with declarative 
>> code.
>>But I think there are still some problems in it. I deployed my jenkins 
>> in the kubernetes cluster and managed my jenkins through the groovy script 
>> and the casc plugin. But once the jenkins is started, I need to modify the 
>> configuration of the casc, then I need to submit the configuration to the 
>> jenkins dashborad, and the submitted configuration is not necessarily 
>> successful, and there is no failure record. In other words, although I have 
>> a casc configuration file, it is difficult for me to ensure that my 
>> environment is consistent with the casc configuration. Or at least let me 
>> know that my current configuration is incorrect, I need to fix it.
>>If we can provide an official jenkins operator to manage jenkins in 
>> kubernetes, it must be great.
>>I hope to hear your opinions.
>>
>> Best wishes 
>> RunzeXia
>>
>> -- 
>> 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/7939b7df-2935-4aeb-a1f5-3f300990119f%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/3278c9bb-a74d-47cf-b695-46da5cef3685%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[夏润泽]

CasC support observer mode is a very powerful and useful function. But we 
could use the k8s jenkins operator to do more things, such as the health 
status of jenkins (whether the configuration is consistent and the 
necessary components are normal)、 automatic update based on Jenkins 
Evergreen

On Tuesday, January 15, 2019 at 4:19:53 PM UTC+8, nicolas de loof wrote:
>
> Introducing a watcher to reload changes has been proposed for 
> Configuration-as-Code: 
> https://github.com/jenkinsci/configuration-as-code-plugin/issues/76
> just need to be implemented ...
>
> Le mar. 15 janv. 2019 à 09:17, Carlos Sanchez  > a écrit :
>
>> I thought about it, and yes it would be interesting to have an operator 
>> that watches a configmap and ensures jenkins is always updated.
>> However with serverless jenkins[1] you wouldn't need to worry about that 
>> anymore (if you can use serverless).
>>
>>
>> [1] 
>> https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870
>>
>> On Tue, Jan 15, 2019 at 6:37 AM 夏润泽 > 
>> wrote:
>>
>>> Hi dev:
>>>In the cloud native domain, kubernetes is an important part, and now 
>>> many software are using kubernetes operator to manage applications in 
>>> kubernetes.
>>>Now we can manage jenkins through groovy scripts, casc plugins, 
>>> etc.In particular, the casc plugin allows us to manage jenkins with 
>>> declarative code.
>>>But I think there are still some problems in it. I deployed my 
>>> jenkins in the kubernetes cluster and managed my jenkins through the groovy 
>>> script and the casc plugin. But once the jenkins is started, I need to 
>>> modify the configuration of the casc, then I need to submit the 
>>> configuration to the jenkins dashborad, and the submitted configuration is 
>>> not necessarily successful, and there is no failure record. In other words, 
>>> although I have a casc configuration file, it is difficult for me to ensure 
>>> that my environment is consistent with the casc configuration. Or at least 
>>> let me know that my current configuration is incorrect, I need to fix it.
>>>If we can provide an official jenkins operator to manage jenkins in 
>>> kubernetes, it must be great.
>>>I hope to hear your opinions.
>>>
>>> Best wishes 
>>> RunzeXia
>>>
>>> -- 
>>> 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/7939b7df-2935-4aeb-a1f5-3f300990119f%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-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6OYTfn4Bn_qJvtimvggJcSpHERm1m%2BTrqyV%2BVrEfYYDPg%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Nicolas De Loof
>

-- 
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/50fe6f42-9d2a-443b-ad95-4b0c660f1fe4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[nicolas de loof]

Introducing a watcher to reload changes has been proposed for
Configuration-as-Code:
https://github.com/jenkinsci/configuration-as-code-plugin/issues/76
just need to be implemented ...

Le mar. 15 janv. 2019 à 09:17, Carlos Sanchez  a écrit :

> I thought about it, and yes it would be interesting to have an operator
> that watches a configmap and ensures jenkins is always updated.
> However with serverless jenkins[1] you wouldn't need to worry about that
> anymore (if you can use serverless).
>
>
> [1]
> https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870
>
> On Tue, Jan 15, 2019 at 6:37 AM 夏润泽  wrote:
>
>> Hi dev:
>>In the cloud native domain, kubernetes is an important part, and now
>> many software are using kubernetes operator to manage applications in
>> kubernetes.
>>Now we can manage jenkins through groovy scripts, casc plugins, etc.In
>> particular, the casc plugin allows us to manage jenkins with declarative
>> code.
>>But I think there are still some problems in it. I deployed my jenkins
>> in the kubernetes cluster and managed my jenkins through the groovy script
>> and the casc plugin. But once the jenkins is started, I need to modify the
>> configuration of the casc, then I need to submit the configuration to the
>> jenkins dashborad, and the submitted configuration is not necessarily
>> successful, and there is no failure record. In other words, although I have
>> a casc configuration file, it is difficult for me to ensure that my
>> environment is consistent with the casc configuration. Or at least let me
>> know that my current configuration is incorrect, I need to fix it.
>>If we can provide an official jenkins operator to manage jenkins in
>> kubernetes, it must be great.
>>I hope to hear your opinions.
>>
>> Best wishes
>> RunzeXia
>>
>> --
>> 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/7939b7df-2935-4aeb-a1f5-3f300990119f%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/CALHFn6OYTfn4Bn_qJvtimvggJcSpHERm1m%2BTrqyV%2BVrEfYYDPg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Nicolas De Loof

-- 
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/CANMVJzmk-ULGcGcPTpCoURQnTwEqwnuwxv6a_ZCFudD6a57g5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[Carlos Sanchez]

I thought about it, and yes it would be interesting to have an operator
that watches a configmap and ensures jenkins is always updated.
However with serverless jenkins[1] you wouldn't need to worry about that
anymore (if you can use serverless).


[1]
https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870

On Tue, Jan 15, 2019 at 6:37 AM 夏润泽  wrote:

> Hi dev:
>In the cloud native domain, kubernetes is an important part, and now
> many software are using kubernetes operator to manage applications in
> kubernetes.
>Now we can manage jenkins through groovy scripts, casc plugins, etc.In
> particular, the casc plugin allows us to manage jenkins with declarative
> code.
>But I think there are still some problems in it. I deployed my jenkins
> in the kubernetes cluster and managed my jenkins through the groovy script
> and the casc plugin. But once the jenkins is started, I need to modify the
> configuration of the casc, then I need to submit the configuration to the
> jenkins dashborad, and the submitted configuration is not necessarily
> successful, and there is no failure record. In other words, although I have
> a casc configuration file, it is difficult for me to ensure that my
> environment is consistent with the casc configuration. Or at least let me
> know that my current configuration is incorrect, I need to fix it.
>If we can provide an official jenkins operator to manage jenkins in
> kubernetes, it must be great.
>I hope to hear your opinions.
>
> Best wishes
> RunzeXia
>
> --
> 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/7939b7df-2935-4aeb-a1f5-3f300990119f%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/CALHFn6OYTfn4Bn_qJvtimvggJcSpHERm1m%2BTrqyV%2BVrEfYYDPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.