Re: Contributing to Jenkins docker plugin

[nicolas de loof]

gt;>> have
>>>>>> many visibility). The code produced is not clean (I took the quick & 
>>>>>> dirty
>>>>>> way).
>>>>>> I would like to setup a discussion if possible with PJ Darton 7 other
>>>>>> current maintainers.
>>>>>>
>>>>>> Thanks for your help
>>>>>> Kind regards
>>>>>>
>>>>> --
>>>>> 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/G-hS9emqG6w/unsubscribe
>>>>> .
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> jenkinsci-de...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/42e6f5f8-daaf-408a-b564-50ff5a92a8a4n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/42e6f5f8-daaf-408a-b564-50ff5a92a8a4n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> 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/CAPfivLDeP89g_8rYJpbTaGh9v6Y37LacE0VOW0iRWaG7wUa_Qw%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDeP89g_8rYJpbTaGh9v6Y37LacE0VOW0iRWaG7wUa_Qw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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/G-hS9emqG6w/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> jenkinsci-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAEGYFEKhcKx6YSa%3D-1hvPWrPB7Lq2Qi3K3cHxhqw7Jp9RZiAUQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAEGYFEKhcKx6YSa%3D-1hvPWrPB7Lq2Qi3K3cHxhqw7Jp9RZiAUQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/a9efcce2-56e1-4a1a-8544-c04cd2732a68n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a9efcce2-56e1-4a1a-8544-c04cd2732a68n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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/CANMVJzna%2BSw6H5L9zK5ARDJsRoK2XrDRk2w1YmcjD0iebsh%2BkA%40mail.gmail.com.

Re: Welcome Ewelina Wilkosz - new Jenkins Governance Board Member

[nicolas de loof]

Congrats, you deserve this recognition for your passionate involvement in
Jenkins community

Le lun. 15 mars 2021 à 19:33, Alyssa Tong  a écrit :

> Welcome Ewelina! Thank you for taking on this role.
>
> On Mon, Mar 15, 2021 at 4:56 AM Oleg Nenashev 
> wrote:
>
>> Dear all,
>>
>> We are happy to announce that we have finished the interim board member
>> selection procedure. The Mar 10 Governance meeting has confirmed Ewelina
>> Wilkosz as a new Jenkins Governance Board member who will replace Marky
>> Jackson in this role. The term will last until the Jenkins elections in
>> late 2022. Ewelina's statement from the 2020 elections is available here
>> <https://www.jenkins.io/blog/2020/10/28/election-candidates/#ewelina-wilkosz>
>> .
>>
>> About Ewelina <https://www.jenkins.io/blog/authors/ewelinawilkosz/>: *Jenkins
>> Contributor since 2017, when she got involved in Jenkins Configuration as
>> Code Plugin development. Voted Most Valuable Contributor in 2018. **She
>> has 14 years of experience in IT, working as a CI/CD consultant since the
>> beginning of 2017. In that role she’s trying to solve* *numerous issues
>> Jenkins users are facing daily - as developers, administrators, maintainers*
>> *.*
>>
>> Welcome aboard Ewelina!
>>
>> Best regards,
>> Oleg Nenashev
>>
>> --
>> 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/CAPfivLC3jALq-E%3DC%3Dt_in_H2_C%3DoaHUdqMo8PLYNOEMFf8Fhqg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLC3jALq-E%3DC%3Dt_in_H2_C%3DoaHUdqMo8PLYNOEMFf8Fhqg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAMBsfbt5kOsZaC%2Bb4996a-u2_0sag1DLz7hQ4SdSH%2BK_E9c8gA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMBsfbt5kOsZaC%2Bb4996a-u2_0sag1DLz7hQ4SdSH%2BK_E9c8gA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
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/CANMVJzmuyKPP1znQgsUVkaGquy868UxXknxHzksbC9aoOYfJww%40mail.gmail.com.

Re: Maintainer role clarification

[nicolas de loof]

Hi.

As you volunteer for it and there's no active one, I'm +100 you become 
maintainer on this plugin

Le mardi 14 mai 2019 10:19:31 UTC+2, Emilio Escobar a écrit :
>
> Hi Nicolas,
>
> I have seen you are still an aws-credentials-plugin maintainer. I can help 
> if you agree.
>
> Cheers.
>
> On Thursday, February 21, 2019 at 7:18:50 PM UTC+1, nicolas de loof wrote:
>>
>> Hi!
>>
>> Over the years I've been working with Jenkins, I've come to adopt or just 
>> patch a few plugins. In some cases, I was only delivering a fix, not really 
>> adopting the plugin per-se. Many of them I've been contacted to review  
>> pull requests while I only provided a fix for a customer but don't use by 
>> myself, so hardly can maintain. As this might have led to some confusion 
>> nowadays, I would like to clarify for future requests that I don't consider 
>> myself an active maintainer on any plugin.  So I would like to formally 
>> tell the community that anyone can consider "my" plugins ready to be 
>> adopted if there isn't already another active maintainer. This typically 
>> includes the few docker-*-plugins I've created or maintained past years. 
>> Some people using them for production would be better candidate for a 
>> maintener role.
>>
>> I hope this will possibly avoid some loops to provide maintainership to 
>> requesters, for plugins that are already de facto without an active 
>> maintainer.
>>
>

-- 
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/a9a77627-79b0-4088-b7b8-415537c8a451%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditional CasC

[nicolas de loof]

Why not just have two distinct docker images ?
Or a custom entrypoint to switch between configuration folders ?

By design JCasC does not include any logic to keep being plain declarative.

Le mar. 7 mai 2019 à 08:30, domi  a écrit :

> I’m not sure I missed something, is there any way to tell the CasC plugin
> load/ignore some configuration files?
> My use case is the following: I have a Dockerimage which contains all
> required configuration files, but in some cases I want to load a different
> security configuration (OAuth vs. Local).
> Is there any way I can do this? (Beside using groovy initscripts instead
> of the CasC configuration files)
> Thanks Domi
>
> --
> 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/D7DA3592-8D8D-4EE5-AA96-D2B1221D7FAA%40fortysix.ch
> .
> 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/CANMVJzm8Uw4NTteJsSsoS4ygApNJBbo%2BGFiQQFuRBTkrqPar0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Maintainer role clarification

[nicolas de loof]

Le jeu. 21 févr. 2019 à 19:44, Oleg Nenashev  a
écrit :

> Thanks for the clarification Nicolas! It should help with transitions. I
> had to go through the same during the last year (putting more than 30
> plugins for adoption). It hurts sometimes, but it is really required to
> keep the focus. Thanks a lot for your contributions to the plugins!
>
> I went through the component list in JIRA, and there are few components
> where you are marked as a lead:
>
>- aws-credentials-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+aws-credentials-plugin>
>- azure-publishersettings-credentials-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+azure-publishersettings-credentials-plugin>
>- ceylon-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+ceylon-plugin>
>- changes-since-last-success-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+changes-since-last-success-plugin>
>- clever-cloud-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+clever-cloud-plugin>
>- container-slaves-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+container-slaves-plugin>
>- docker-custom-build-environment-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+docker-custom-build-environment-plugin>
>- docker-java-api-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+docker-java-api-plugin>
>- docker-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+docker-plugin>
>- docker-slaves-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+docker-slaves-plugin>
>- jna-posix-api-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+jna-posix-api-plugin>
>- jnr-posix-api-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+jnr-posix-api-plugin>
>- naginator-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+naginator-plugin>
>- one-shot-executor-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+one-shot-executor-plugin>
>- slave-prerequisites-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+slave-prerequisites-plugin>
>- timemachine-plugin
>
> <https://issues.jenkins-ci.org/issues/?jql=project+%3D+JENKINS+AND+component+%3D+timemachine-plugin>
>
> Would you like us to mark all these plugins for adoption and remove you as
> a default assignee (or change to otheractive maintainers in some components
> like Docker)?
>

Please do.
I'd like to keep maintainer role on clever-cloud plugin and
time-machine-plugin as those are still work in progress on my side.



> Best regards,
> Oleg
>
>
> On Thursday, February 21, 2019 at 7:18:50 PM UTC+1, nicolas de loof wrote:
>>
>> Hi!
>>
>> Over the years I've been working with Jenkins, I've come to adopt or just
>> patch a few plugins. In some cases, I was only delivering a fix, not really
>> adopting the plugin per-se. Many of them I've been contacted to review
>> pull requests while I only provided a fix for a customer but don't use by
>> myself, so hardly can maintain. As this might have led to some confusion
>> nowadays, I would like to clarify for future requests that I don't consider
>> myself an active maintainer on any plugin.  So I would like to formally
>> tell the community that anyone can consider "my" plugins ready to be
>> adopted if there isn't already another active maintainer. This typically
>> includes the few docker-*-plugins I've created or maintained past years.
>> Some people using them for production would be better candidate for a
>> maintener role.
>>
>> I hope this will possibly avoid some loops to provide maintainership to
>> requesters, for plugins that are already de facto without an active
>> maintainer.
>>
> --
> 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

Maintainer role clarification

[nicolas de loof]

Hi!

Over the years I've been working with Jenkins, I've come to adopt or just
patch a few plugins. In some cases, I was only delivering a fix, not really
adopting the plugin per-se. Many of them I've been contacted to review
pull requests while I only provided a fix for a customer but don't use by
myself, so hardly can maintain. As this might have led to some confusion
nowadays, I would like to clarify for future requests that I don't consider
myself an active maintainer on any plugin.  So I would like to formally
tell the community that anyone can consider "my" plugins ready to be
adopted if there isn't already another active maintainer. This typically
includes the few docker-*-plugins I've created or maintained past years.
Some people using them for production would be better candidate for a
maintener role.

I hope this will possibly avoid some loops to provide maintainership to
requesters, for plugins that are already de facto without an active
maintainer.

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

Re: jenkins official kubernetes operator

[nicolas de loof]

>
>
>
> I forgot to mention that plugins are separated in two groups: required by
> jenkins-operator(used to configure Jenkins)(A) and required by user(B).
> A:
> - they are installed by jenkins-operator before Jenkins can start up
> - every single change requires restart of Jenkins master pod(which I want
> to avoid)
> - user can override versions
> - user can add more plugins but it cause restart of Jenkins master pod
> B:
> - they are installed by jcasc plugins
> - requires restart of Jenkins but no Kubernetes pod
> - it should be used by users to install plugins
>
>
JCasC do support plugin installation but this is pretty hack-ish and
demonstrated to come with some troubles. I strongly recommend you use
external tool to install users' plugin. As you already have one for
A-plugins, better to do the same for B-plugins.

also consider https://issues.jenkins-ci.org/browse/JENKINS-53767: a general
plugin management tool would be helpful here.

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

Re: jenkins official kubernetes operator

[nicolas de loof]

Have you checked overlap with https://github.com/VirtusLab/jenkins-operator
?
I was discussing with the authors to get this contributed in jenkinsci
organization. Should avoid a concurrent effort to happen on same topic.

Le lun. 21 janv. 2019 à 05:54, Rick  a écrit :

> I'm in
>
> On Monday, January 21, 2019 at 6:44:11 AM UTC+8, marky.r...@gmail.com
> wrote:
>>
>> 夏润泽 and I started documenting this JEP and initial code. If anyone is
>> interested in helping let us know.
>>
>> On Sunday, January 20, 2019 at 5:55:45 AM UTC-8, 夏润泽 wrote:
>>>
>>> I also think that creating a prototype is a good suggestion, we can
>>> contact on gitter
>>>
>>> On Sunday, January 20, 2019 at 8:05:51 PM UTC+8, Marky Jackson wrote:

 I agree that creating a prototype is the best path forward.
 We can split the work up for documenting that yaml format and the cli
 options.
 I will wait to hear from RunzeXia and we can have further discussion
 (please reach out to me on gitter or via email).
 Thanks kindly.
 {
"regards" : {
 "name" : “marky”,
 "phone" : "+1 (408) 464 2965”,
 "email" : “marky.r...@gmail.com",
 "team" : "jackson5“
 }
 }

 On Jan 20, 2019, at 2:22 AM, Oleg Nenashev  wrote:

 Hi all,

 After reading the proposal from RunzeXia in this pull request
 , I think that
 the official Kubernetes Operator could be built on the top of the Custom
 WAR/Docker Packager 
 which already supports managing Jenkins versions, plugins and
 configurations via JCasC/Groovy (blog
 ). It's
 configured via YAML and it can already produce Docker images and standalone
 WAR files.

 I believe that CWP could be adjusted to support the Kubernetes Operator
 mode, even for Kubernetes deployments without Docker. The same Custom War
 Packager is used in Jenkins X Serverless, so we can make the configurations
 somewhat portable between "Serverless Jenkins" modes and more classic K8s
 operators. What do you think?

 Who/how can we go about starting this? I will gladly upload my code but
> it might be best to have some guidelines or plan
>

 If the Kubernetes Operator requires a lot of design and requires
 long-term compatibility, it might be reasonable to create a prototype,
 agree on that in this thread and then to create a specification Jenkins
 Enhancement Proposal  to document
 YAML formats and the command line options.

 Best regards,
 Oleg


 On Sunday, January 20, 2019 at 3:05:27 AM UTC+1, marky.r...@gmail.com
 wrote:
>
> Who/how can we go about starting this? I will gladly upload my code
> but it might be best to have some guidelines or plan
>
> On Thursday, January 17, 2019 at 9:25:27 PM UTC-8, 夏润泽 wrote:
>>
>> Very good, I think we can start working from your operator
>>
>> On Wednesday, January 16, 2019 at 12:42:38 AM UTC+8, Marky Jackson
>> wrote:
>>>
>>> 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...@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-de...@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 jenkins

Re: GSoC proposal on OpenAPI REST API spec generator for Jenkins core and plugins

[nicolas de loof]

Le dim. 20 janv. 2019 à 03:40, martinda  a
écrit :

> Hello,
>
> There is a GSoC proposal on automatically generating the Jenkins REST API
> 
> for core and plugins, from a REST API spec generator like OpenAPI. I can
> kind of see this as being possible for future plugins, but for all the
> existing code it would be a difficult exercise in extracting the spec from
> annotations, source code, and javadocs.
>


This is exactly what Configuration as code is doing, so you could reuse
this mechanism (or better: get this natively supported by stapler)



> I am trying to clarify the GSoC proposal, and frame it in way that some
> kind of progress can be made. Would anyone have a suggestion here?
>
> There has been an effort in that direction by Cliffano with
> swaggy-jenkins. Cliffano told me that he reversed engineered the the
> response model definition from the HTTP response payload, because in early
> 2017 there might have been an effort to move to GraphQL instead of REST. I
> wonder if this is still relevant and how it could affect the GSoC proposal.
>
> I also found a closed PR on stapler
>  to make stapler more
> declarative, and I wonder if this could lead in some way towards automatic
> REST API generation. Is that PR something a potential GSoC student could
> take on?
>
> Best,
> Martin d'Anjou
> Jenkins GSoC Org Admin Team
>
> --
> 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/2b14b028-1bae-4400-abcf-544cf5669cb7%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/CANMVJzkLx89JpJVbghxqPCK9f9pd-1BZOiPJk_H3g4tDhZ7WWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins official kubernetes operator

[nicolas de loof]

I guess you might be interested by
https://github.com/VirtusLab/jenkins-operator

Le jeu. 17 janv. 2019 à 15:06, 夏润泽  a écrit :

> 非常好，我想我们可以从您的运营商开始工作
>
> 周一，2019年1月16日星期三上午12:42:38 UTC + 8，Marky Jackson写道：
>>
>> 我已完成了一些当前的操作员工作，并提交了关于操作员的即将到来的演讲。
>> 我很想甚至只是修补这个想法
>>
>> {
>>“问候”：{
>> “name”：“marky”，
>> “phone”：“ + 1（408）464 2965 ”，
>> “email”：“ marky.r ... @ gmail.com ”，
>> “team”：“杰克逊5“
>> }
>> }
>>
>> 在2019年1月15日上午8:38，Jesse Glick < jgl ... @ cloudbees.com >写道：
>>
>> 在2019年1月15日星期二上午7:56夏润泽< junw ... @ gmail.com >写道：
>>
>> 我们可以使用k8s jenkins运算符来做更多的事情，比如jenkins的健康状态（配置是否一致以及必要的组件是否正常），基于Jenkins
>> Evergreen的自动更新..
>>
>>
>> 目前在这个领域没有做任何事情。听起来像是一个
>> 明智的补充
>>
>> https://jenkins.io/sigs/cloud-native/#areas-for-improvement
>>
>> -
>> 您收到此邮件是因为您订阅了Google网上论坛“Jenkins Developers”群组。
>> 要取消订阅此论坛并停止接收来自该论坛的电子邮件，请发送电子邮件至jenkinsci-de ... @ googlegroups.com。
>> 要在网络上查看此讨论，请访问https://groups.google.com/d/ msgid / jenkinsci-dev / 
>> CANfRfr24Y6Vpq2YnUXT3BubDuuzpT
>> Xmw-fCgoeeVpM0PTMx％3Dsw％40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr24Y6Vpq2YnUXT3BubDuuzpTXmw-fCgoeeVpM0PTMx%3Dsw%40mail.gmail.com>
>> 。
>> 有关更多选项，请访问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/57f120ee-2691-4668-ae37-afa5ef0b8748%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/57f120ee-2691-4668-ae37-afa5ef0b8748%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJzmNZ4SGauE6M1EV2Woyrdt4tba88csvxrByoBwsNyRCFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new home for Jenkins

[nicolas de loof]

d
>> >> 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/CAN4CQ4z%2BQzaBc1pDtciKXH%3DMhB3vUR%3DCShiFbwy__2W6eEH_EQ%40mail.gmail.com
>> >> <
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z%2BQzaBc1pDtciKXH%3DMhB3vUR%3DCShiFbwy__2W6eEH_EQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >.
>> >> 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
>> > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/jenkinsci-dev/290A37BE-FEDF-4707-8637-775343917FC0%40gmail.com
>> > <
>> https://groups.google.com/d/msgid/jenkinsci-dev/290A37BE-FEDF-4707-8637-775343917FC0%40gmail.com?utm_medium=email&utm_source=footer
>> >.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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/5f689e24-719d-2e82-94fa-b24bb65f4ca9%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> https://github.com/LinuxSuRen
>
> --
> 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/CAMM7nTGq6xWQYXQCo_PrA6uibBG%3DVhMKwMEX0xKwMr%3D3mVcq9w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTGq6xWQYXQCo_PrA6uibBG%3DVhMKwMEX0xKwMr%3D3mVcq9w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJzmzZyFcBCh2oSQq_cAXjCYPDmdAme2t2LCEumoJfDPPtw%40mail.gmail.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
>> <https://groups.google.com/d/msgid/jenkinsci-dev/7939b7df-2935-4aeb-a1f5-3f300990119f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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
> <https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6OYTfn4Bn_qJvtimvggJcSpHERm1m%2BTrqyV%2BVrEfYYDPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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: Any idea how to release https://github.com/jenkinsci/xstream-fork

[nicolas de loof]

As discussed already here
<https://groups.google.com/forum/#!searchin/jenkinsci-dev/xstream-fork%7Csort:date/jenkinsci-dev/nZvl6Ra3P-M/7PPE3zX4CwAJ>,
the *-fork repository have been created so that the jenkins flavours of
those library are actual forks from upstreams, so we can better propose our
patches and/or pull upstream fixes.
Now, if you feel this is useless, fell free to remove the unnecessary ones.

Le mar. 11 déc. 2018 à 13:31, Oliver Gondža  a écrit :

> On 11/12/2018 12.55, Oleg Nenashev wrote:
> > `xstream` is what we use in Jenkins nowadays.
> > `xstream-fork` has been created by Nicolas de Loof at some point, but
> > this repository has never been updated to incorporate Jenkins-specific
> > patches. And I am not sure whether it has passed the full test cycle.
> > There is a splitbrain between the repos, and their README files are
> > misleading. Since 2016 there were pull requests submitted against both
> > repos, and it made the situation worse.
> >
> > Whomever wants to update XStream, we firstly need to resolve the
> > splitbrain issue. Switching from a custom XStream fork to the official
> > XStream releases is something we should do IMHO, but it needs to be
> > tested a LOT before we do it. Any XStream change may cause Jenkins
> > startup issues and, potentially, security issues if JEP-200 classfilter
> > hooks stop working.
>
> Well, that surely is a noble goal but I am not sure if doable ta all. My
> impressions, mostly from https://github.com/x-stream/xstream/pull/106,
> are this will not happen.
>
> --
> 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/8b283fea-a325-ce21-4dac-f2c50d4df8ef%40gmail.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/CANMVJznNw9afMN_0x15b%2Bhs8x4-yyeOdH683HaRB6hh%2B9MLkNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

JCasC requirement for plugins developers

[nicolas de loof]

0+.

You just need CasC as a test dependency and a sample yaml file for your
component


  io.jenkins
  configuration-as-code
  1.0
  test


public class ConfigAsCodeTest {

@Rule public JenkinsRule r = new JenkinsRule();

@Test public void should_support_configuration_as_code() throws Exception {

ConfigurationAsCode.get().configure(ConfigAsCodeTest.class.getResource("configuration-as-code.yml").toString());
assertTrue( /* check plugin has been configured as expected */ );
}

Benefits for you to write such a testcase :

   - You confirm your plugin is well design regarding JCasC conventions
   - You offer users a sample configuration file
   - You will be able to detect breaking changes that may impact your users

<https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/REQUIREMENTS.md#rule-4-ping-us-in-case-of-doubts>Rule
4: ping us in case of doubts

Really, if you need any assistance getting your plugin to support JCasC,
want code review or anything, ping us on Gitter
<https://gitter.im/jenkinsci/configuration-as-code-plugin>.


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

Re: POTD: Jenkinsfile Runner

[nicolas de loof]

Le jeu. 4 oct. 2018 à 08:04, Oleg Nenashev  a
écrit :

> Hi Nicolas,
>
> I am ready to execute on the request. Please confirm that all the data is
> backed up in your fork.
>

Confirmed
Please do


>
> and fork https://github.com/kohsuke/jenkinsfile-runner
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fkohsuke%2Fjenkinsfile-runner&sa=D&sntz=1&usg=AFQjCNH4P8HuBix_ko7yf-u8z8eSAAOFCA>
>> as a replacement.
>>
>
> No fork, please, it will only contribute to the confusion.
> My proposal is to move the project then. I will work with Kohsuke to do
> that once the target repo is deleted
>

+1


>
> BR, Oleg
>
> On Tuesday, October 2, 2018 at 5:45:38 PM UTC+2, nicolas de loof wrote:
>>
>> all those changes are related to my version's README.md
>> <https://github.com/ndeloof/jenkinsfile-runner/compare/master...jenkinsci:master#diff-04c6e90faac2675aa89e2176d2eec7d8>,
>> no impact on KK's repository
>>
>> Le mar. 2 oct. 2018 à 17:33, Jesse Glick  a écrit :
>>
>>> On Tue, Oct 2, 2018 at 10:13 AM nicolas de loof
>>>  wrote:
>>> > DELETE the jenkinsci/jenkinsfile-runner repository
>>>
>>> What about
>>>
>>>
>>> https://github.com/ndeloof/jenkinsfile-runner/compare/master...jenkinsci:master
>>>
>>> ? That should be upstreamed first, no?
>>>
>>> --
>>> 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/CANfRfr0rfAkiB8vMAczAApGQm-EVGK3_SFsPiR6sDLz0RreSOw%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/b6870795-6ef3-419d-9c37-793248006c33%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/b6870795-6ef3-419d-9c37-793248006c33%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJznNOWAJo_jiqM0hJhOC%2BmbYVmnaBK1C9qFDCTi1h5QFUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[nicolas de loof]

all those changes are related to my version's README.md
<https://github.com/ndeloof/jenkinsfile-runner/compare/master...jenkinsci:master#diff-04c6e90faac2675aa89e2176d2eec7d8>,
no impact on KK's repository

Le mar. 2 oct. 2018 à 17:33, Jesse Glick  a écrit :

> On Tue, Oct 2, 2018 at 10:13 AM nicolas de loof
>  wrote:
> > DELETE the jenkinsci/jenkinsfile-runner repository
>
> What about
>
>
> https://github.com/ndeloof/jenkinsfile-runner/compare/master...jenkinsci:master
>
> ? That should be upstreamed first, no?
>
> --
> 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/CANfRfr0rfAkiB8vMAczAApGQm-EVGK3_SFsPiR6sDLz0RreSOw%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/CANMVJzmhsk7L04Rch2y5SieunEbCF4Bjuk9KMoaajZjZUgYWDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[nicolas de loof]

Based on the fact custom-war-packager already support KK's approach 
I'm asking jenkinsci organisation owners to DELETE the 
jenkinsci/jenkinsfile-runner repository, and 
fork https://github.com/kohsuke/jenkinsfile-runner as a replacement.

My own version (https://github.com/ndeloof/jenkinsfile-runner) will stay 
there for those interested in trying to reconcile both.



Le jeudi 6 septembre 2018 17:10:52 UTC+2, Liam Newman a écrit :
>
> Oleg,
> +1 for cleanup, definitely.  The path you propose overall sounds good to 
> me. 
>
> On Thursday, September 6, 2018 at 6:40:23 AM UTC-7, Oleg Nenashev wrote:
>>
>> Obviously, step (5) is a bad idea then. Could we just have 2 repos 
>> without "fork" relations then?
>> If the codebase is not shared, it would help.
>>
>> As you can guess I have my strong opinion about classloader voodoo in 
>>> KK's approach to a jenkinsfile-runner CLI.
>>>
>> Fine for PoC IMHO. It improves performance, and it may be useful in cases 
>> when we want to have fast builds with really short initialization times. I 
>> was doing some performance hacks for similar purposes a while ago (actually 
>> some even weirder hacks). Obviously, a final implementation should not be 
>> based on Jenkins Test Harness and JenkinsRule, some Jenkins core patches 
>> will likely be needed.
>>
>>
>> On Thu, Sep 6, 2018 at 3:31 PM nicolas de loof  
>> wrote:
>>
>>> please note ndeloof/jenkinsfile-runner is a complete different design vs 
>>> KK initial prototype
>>> they don't share architecture nor git history (only few java classes)
>>>
>>> so you'll have to choose one approach over the other
>>>
>>> As you can guess I have my strong opinion about classloader voodoo in 
>>> KK's approach to a jenkinsfile-runner CLI.
>>>
>>> Le jeu. 6 sept. 2018 à 15:27, Baptiste Mathus  a 
>>> écrit :
>>>
>>>> +1 for cleaning up. Like we recommend for plugins, it would be nice 
>>>> that canonical repo location is more clearly the one under jenkinsci org
>>>>
>>>> Le jeu. 6 sept. 2018 à 15:24, Oleg Nenashev  a 
>>>> écrit :
>>>>
>>>>> Hi all,
>>>>>
>>>>> It seems we have a splitbrain issue in this project.
>>>>> Currently there is the following fork tree:
>>>>>
>>>>>- https://github.com/kohsuke/jenkinsfile-runner
>>>>>   - https://github.com/ndeloof/jenkinsfile-runner
>>>>>  - https://github.com/jenkinsci/jenkinsfile-runner
>>>>>  
>>>>> Jenkinsfile Runner in Kohsuke's repo has the most number of stars + 
>>>>> there is a number of issues and pull requests. It makes the jenkinsci 
>>>>> repo 
>>>>> unsearchable, and it can also confuse users looking for a place to report 
>>>>> issues / propose patches.
>>>>>
>>>>> I propose to do the following:
>>>>>
>>>>>1. Remove https://github.com/jenkinsci/jenkinsfile-runner and 
>>>>>evacute the branches somewhere
>>>>>2. Move https://github.com/kohsuke/jenkinsfile-runner to jenkinsci 
>>>>>org (yes, move, not fork)
>>>>>3. Rename the current master branch to "kohsuke-master"
>>>>>4. Reintegrate the current 
>>>>>https://github.com/jenkinsci/jenkinsfile-runner state as a master 
>>>>>branch
>>>>>5. See if "master" and "kohsuke-master" can be merged
>>>>>
>>>>> WDYT?
>>>>>
>>>>> BR, Oleg
>>>>>
>>>>> On Wednesday, April 4, 2018 at 9:30:15 PM UTC+2, Kohsuke Kawaguchi 
>>>>> wrote:
>>>>>>
>>>>>> Ouch, that's a shame. It looked like an interesting project, I hope 
>>>>>> my writing to you didn't trigger that.
>>>>>>
>>>>>> You say "stress builds and also to burn in our build agents" -- can 
>>>>>> you elaborate on that? It sounds like you are trying to warm up a cache 
>>>>>> or 
>>>>>> something, but I'm not sure what that means in the context of builds.
>>>>>>
>>>>>> On Wed, Apr 4, 2018 at 11:15 AM Tom Shaw  wrote:
>>>>>>
>>>>>>> Hi Kohsuke,
>>>>>>>
>>>>>>> Thank

jep/213 "Configuration Storage API" vs SideCar

[nicolas de loof]

Hi,

I've read JEP-213 proposal
<https://github.com/jenkinsci/jep/blob/master/jep/213/README.adoc> with
lots of interest,

IIUC there's no plan to change the configuration granularity (we still will
have one configuration entry per legacy xml file) neither do we plan to
change the data being stored here (plain component XStream dump, no plan to
filter default values)

Then, I wonder we could adopt a simpler (?) approach relying on a sidecar
configuration container.

i.e a typical k8s pattern for legacy applications is to deploy a sidecar to
act as http proxy, and (for sample) add support for https or other
improvements without changing a single bit of the existing codebase.

doing so we could offer Cloud Native configuration storage for Jenkins


[image: Capture d’écran 2018-10-01 à 12.47.44.png]
(illustration from Oreilly's "Designing-Distributed-Systems :
PatternsParadigms")

Benefit I can see doing so is that we just don't need to wait for a new
jenkins-core release, this can be adopted without delay.

wdyt ?

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

Re: Adoption of ec2-plugin

[nicolas de loof]

+1, this plugin need a maintainer, and it's great you can get some
dedicated time for it

Le mar. 18 sept. 2018 à 05:24,  a écrit :

> Hi,
>
> I would like to be maintainer of the ec2 plugin on behalf of my company
>  (Coveo). We have a pretty active fork (https://github.com/coveo/ec2-pl
> ugin) where we have added features such as spot instances without
> bidding and fallback when there are no spot instance capacity
> available.
>
> As for myself, here's my Github account:
> https://github.com/julienduchesne
> And my jenkins id is: julienduchesne.
>
> I'd be able to dedicate about 4-8 hours a week on this plugin.
>
> Let me know what you think.
>
> Julien Duchesne
>
> On Sunday, August 19, 2018 at 9:06:40 AM UTC-4, Oleg Nenashev wrote:
>>
>> Thanks for the confirmation, Francis!
>> I also support having more contributors.
>>
>> Fabrizio, I have granted you write permissions and made you a default
>> assignee.
>> You should get an invitation to the jenkinsci organization soon.
>>
>> Best regards,
>> Oleg Nenashev
>>
>>
>> On Friday, August 17, 2018 at 7:34:16 PM UTC+2, F.Manfredi Furuholem
>> wrote:
>>>
>>> Hi,
>>> I'd like to adopt the ec2-plugin. I discussed briefly with the maintainer
>>>  and he doesn't have objection.
>>> My credential are :
>>> GitHub Login: thoulen
>>> Jenkins Login: thoulen
>>>
>>> I will send a pull request soon.
>>>
>>> Br
>>> FM
>>>
>>>
>>> --
> 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/86e7eef4-36ff-483f-8735-e9314dfeb8f9%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/CANMVJznbHVh2AyNuaHyf%2BUGyRtjm5YjQpCHdzCU83_i-OgCu-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

[nicolas de loof]

braries
>>>>>>>
>>>>>>> Over the past year, I've done some deep-dive 1:1 conversations with
>>>>>>> some Jenkins users and I felt something like this might move the needle 
>>>>>>> for
>>>>>>> them in an important way.
>>>>>>>
>>>>>>> I'd love to hear any reactions on your side. Could something like
>>>>>>> this be important for you, does it miss any key points for you? If you
>>>>>>> mentally picture a perfect version of this, what would that do, and how
>>>>>>> would you use?
>>>>>>>
>>>>>>> Let me know!
>>>>>>>
>>>>>>> --
>>>>>>> Kohsuke Kawaguchi
>>>>>>>
>>>>>> --
>>>>>> Kohsuke Kawaguchi
>>>>>>
>>>>> --
>>>>> Kohsuke Kawaguchi
>>>>>
>>>> --
>>> 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/452ee425-972d-4563-920e-cbb6644bacab%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/452ee425-972d-4563-920e-cbb6644bacab%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CANWgJS5B1k5w5HYLGYugQz1mOBg1%2BesYqp0Ccok1Z_Esh%2BYeJg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5B1k5w5HYLGYugQz1mOBg1%2BesYqp0Ccok1Z_Esh%2BYeJg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJzkPHTfhQT8Xp7qTGbTttLpVdjYQY%3DV0LAMVn6px5mk5AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

credentials vs doFillxxItems collision

[nicolas de loof]

Hi,

in a plugin I'm developing I need to let end-user configure credentials and
an organisation ID selected from a list. This list is populated based on
selected credentials.

The issue I have is that doFillOrganisationIdItems() is invoked as form is
rendered with empty credentials, seems to me there's some race condition as
the credentials select list get populated in parallel. But
doFillOrganisationIdItems
never get invoked with the actually selected credentialsId

Does this ring any bell ? Known bug ? Possible workaround ?

-- 
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/CANMVJzkmigYcKS7fCGjfVGb29m-PO_%3DaT%2BMO3UvOb7q8m0n_Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[nicolas de loof]

right, this option indeed is used to add some jars to the higher level
classloader
(
https://github.com/jenkinsci/winstone/blob/d806054073b86d1420ff8fd1cc9bc173ef016c7c/src/main/java/winstone/Launcher.java#L110
)

2018-05-18 23:31 GMT+02:00 Jesse Glick :

> On Fri, May 18, 2018 at 3:19 PM, nicolas de loof
>  wrote:
> > I'm not using custom-war-packager, but --commonLibFolder jenkins.war
> > launcher option.
>
> Never heard of it, and likely does not work for this purpose. You need
> an entry in `jenkins.war!/WEB-INF/lib/*.jar` as I said.
>
> --
> 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/CANfRfr3rMm-CTXH-TpKTyysL0WnOKKAQ41gbHHQOYCJeaV
> TmxA%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/CANMVJz%3DzwUQxouaNSi3FfuG90M2wX_9noM%3DzyW--eUzZ-BweTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[nicolas de loof]

didn't help unfortunately. Still get NoClassDefFoundError:
hudson/model/listeners/RunListener

note : I'm not using custom-war-packager, but --commonLibFolder jenkins.war
launcher option. Not sure this is commonly used ...

2018-05-18 18:53 GMT+02:00 nicolas de loof :

> Thanks for the tip
>
> Le ven. 18 mai 2018 à 18:50, Jesse Glick  a écrit :
>
>> On Fri, May 18, 2018 at 9:03 AM, nicolas de loof
>>  wrote:
>> > I'm writing an extension to jenkins that can't be packaged as a plugin
>> (need
>> > to be ran before plugins get loaded)
>>
>> I think what you are looking for is to use a standard plugin layout
>> but replacing
>>
>> hpi
>>
>> with
>>
>> jenkins-module
>>
>> and then add it to the list here:
>>
>> https://github.com/jenkinsci/jenkins/blob/ac749d669d6ba8bd77c0827c8705c9
>> 454f973a6a/war/pom.xml#L95-L134
>>
>> or use `custom-war-packager` to retrofit it into an existing
>> `jenkins.war` artifact.
>>
>> (Most of these actually could be converted to regular plugins, I
>> think; it is only those things which genuinely need to run code before
>> the Jenkins plugin manager is initialized which must be modules, such
>> as `ConfidentialStore` implementations.)
>>
>> --
>> 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/CANfRfr2w9%2BJmfXJh-X63u3smvQstvV6JgGM2T4ML76K%
>> 3DXoBZ3Q%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/CANMVJzncsaHrzxar7iP2d2As_0Wgf9nNe8P53vMsUoUQmoD%3D1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[nicolas de loof]

Thanks for the tip

Le ven. 18 mai 2018 à 18:50, Jesse Glick  a écrit :

> On Fri, May 18, 2018 at 9:03 AM, nicolas de loof
>  wrote:
> > I'm writing an extension to jenkins that can't be packaged as a plugin
> (need
> > to be ran before plugins get loaded)
>
> I think what you are looking for is to use a standard plugin layout
> but replacing
>
> hpi
>
> with
>
> jenkins-module
>
> and then add it to the list here:
>
>
> https://github.com/jenkinsci/jenkins/blob/ac749d669d6ba8bd77c0827c8705c9454f973a6a/war/pom.xml#L95-L134
>
> or use `custom-war-packager` to retrofit it into an existing
> `jenkins.war` artifact.
>
> (Most of these actually could be converted to regular plugins, I
> think; it is only those things which genuinely need to run code before
> the Jenkins plugin manager is initialized which must be modules, such
> as `ConfidentialStore` implementations.)
>
> --
> 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/CANfRfr2w9%2BJmfXJh-X63u3smvQstvV6JgGM2T4ML76K%3DXoBZ3Q%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/CANMVJzkPGbqctsifZmoTXixvV3mFRUw2ip7CWQTELR%2B_uuQJtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

To be honest, I can't see any benefit in short terms to introduce this just
because at some time we might wish to change casc-plugin handling of _some_
metadata that would introduce a breaking change.
At the time such a thing actually happens, we could easily introduce a top
level "version: 2" pseudo-property so unlock such a breaking change (just
like docker-compose did by the way). Or we can just have a 2.x branch for
configuration-as-code plugin and keep 1.x for security fixes only. So that
if you want your yaml config to rely on this, you just need to install 2.x
plugin.




2018-05-18 18:09 GMT+02:00 Jeff Thompson :

> I agree on the value of having a version identifier. At some level, there
> is a structure that may change, as anything tends to do over time.
> Stephen’s description of a meta-schema version shows the existence of one
> such structure.
>
> In my experience there have been times where I created a version
> identifier for something and didn’t end up using it. But I can’t think of
> an instance where keeping that at version 1 was ever a burden. There have
> been other times where I didn’t add a version identifier and later wished I
> had. And other times where I created one that I didn’t know I needed and
> was later glad I had.
>
> Jeff
>
>
>
> On May 17, 2018, at 5:44 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> But I still think you should include the (let’s invent a different name to
> show the purpose) meta-schema version
>
> Most likely the meta-schema version will always be 1, but if you ever need
> to revise then you will thank Jesse and I for suggesting it.
>
> CaaC has a schema for generating the schema at runtime... this is the
> meta-schema... it says things like: Java Maps are represented by , use
> the @Symbol as a , etc
>
> That is what the meta-schema version represents. If it changes then you
> are saying the way of binding between yaml and runtime (in the general
> sense) has changed.
>
> On Tue 15 May 2018 at 19:30, nicolas de loof 
> wrote:
>
>> I've added a section on this topic in JEP-201: https://github.com/
>> jenkinsci/jep/tree/master/jep/201#versioning
>>
>> We can already generate a json-schema you can use to validate your yaml
>> file(s) before applying configuration.
>> What you miss is a tool to convert jenkins-core + plugins.spec -> json
>> schema.
>> This is something we could package as well (something comparable to
>> jenkinsfile-runner) or even provide "as a service".
>>
>> We could also get such a tool both generate a schema and validate your
>> config, as it seems there's not  (yet) so much text editors to support
>> json schema validation in yaml
>>
>> Would this help ?
>>
>> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy :
>>
>>> (replies inline)
>>>
>>> On Tue, 15 May 2018, nicolas de loof wrote:
>>>
>>> > 2018-05-15 0:20 GMT+02:00 Liam Newman :
>>> >
>>> > >
>>> > > Putting all that aside (as that is not the original point of this
>>> thread),
>>> > > the original suggestion was to include a version field in the CasC
>>> YAML.
>>> > > You said it would not work because the version would have to take
>>> into
>>> > > account the core version and versions of all plugins, otherwise it
>>> might
>>> > > break. Does that mean the CasC YAML could break _any time_  I
>>> upgrade any
>>> > > component? Doesn't that rather defeats the purpose of CasC?
>>> > >
>>> >
>>> > Yes indeed. CasC doesn't have it's own model, everything is based on
>>> actual
>>> > java code discovery at runtime. So upgrading core or any plugin is
>>> changing
>>> > this model. CasC targets reproducibility and immutability use-cases.
>>> If you
>>> > want to upgrade anything you need to test it before.
>>>
>>>
>>> Testing of changes between plugin versions was something I had great
>>> difficulty
>>> with for Groovy-scripting-based configuration, which was much more
>>> common prior
>>> to Configuration as Code. Do you have suggestions for administrators
>>> such as
>>> myself on how I might validate that my configuration YAML is
>>> correct/applies
>>> between any core or plugin upgrades?
>>>
>>> This gets to the underlying concern I had in mind when starting this
>>> thread, as
>>> an administrator, how will I know that my configuration appl

service library in Jenkins

[nicolas de loof]

Hi there,

I'm writing an extension to jenkins that can't be packaged as a plugin
(need to be ran before plugins get loaded) so I created an InitLoader as a
Service


@MetaInfServices
public class InitListener implements InitReactorListener {

@Override
public void onTaskStarted(Task task) {
System.out.println("started :" + task.toString());
}
...
}

When Jenkins starts I get this error =

GRAVE: Failed to initialize Jenkins
hudson.util.HudsonFailedToLoad: java.lang.NoClassDefFoundError:
hudson/init/InitReactorListener
at hudson.WebAppMain$3.run(WebAppMain.java:247)
Caused by: java.lang.NoClassDefFoundError: hudson/init/InitReactorListener
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:560)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at com.google.common.collect.Lists.newArrayList(Lists.java:139)
at com.google.common.collect.Lists.newArrayList(Lists.java:119)
at jenkins.InitReactorRunner.buildReactorListener(InitReactorRunner.java:63)
at jenkins.InitReactorRunner.run(InitReactorRunner.java:48)
at jenkins.model.Jenkins.executeReactor(Jenkins.java:1096)
at jenkins.model.Jenkins.(Jenkins.java:900)
at hudson.model.Hudson.(Hudson.java:85)
at hudson.model.Hudson.(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:233)


For a reason I can't get, this service when loaded can't access jenkins.war
core classes.

I'm running from plain jenkins.war

java -jar jenkins-2.107.3.war --commonLibFolder=./lib/


Any thoughts ?

-- 
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/CANMVJz%3D3aDA2053-cu5oZYU3S%3DXwgXWQkPL2WEqMweuQgDO7Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[nicolas de loof]

> The credentials domain syntax, IIRC something like

system:
  ? # global
  : -credentials
# …

baffles everyone who sees it. Just because internally `credentials`
uses a `Map` from (I guess) domains to lists of credentials does not
mean you must reflect that in YAML syntax. You should rather model a
list of credentials, each of which may have an optional attribute for
the domain (ID?).


We received comparable feedback many times, it seems for most people yaml
is json without quotes, and more complex notations just confuse the reader.
In the meantime for internal design reasons we introduced a model for the
parsed yaml tree, and as a result of this feedback this model as been
limited to only support simplest structures : Lists and maps, with only
support for strings as key.


As a result, here is how a global username/password system credential entry
looks like :

credentials:
  system:
domainCredentials:
  - credentials:
  - usernamePassword:
  scope:SYSTEM
  id:   sudo_password
  username: root
  password: ${SUDO_PASSWORD}


> Using Job DSL Groovy to create jobs is fine as a short-term workaround
but should not be how `TopLevelItem`s are defined in 1.0 I think.


Alternate solution will require some significant changes in core (Job
hierarchy highly relies on hand-written json parsing)
For 1.0 my plan is to propose this job-dsl configuration support to be
owned by job-dsl plugin itself, so users who want to rely on it can, and
this doesn't close the door to an alternate approach in (near?) future.


2018-05-08 21:10 GMT+02:00 nicolas de loof :

>
>
> 2018-05-08 21:08 GMT+02:00 Liam Newman :
>
>>
>> Just FYI: Nicolas asked a question of me in a GH comment:
>> https://github.com/jenkinsci/jep/commit/78bede6c731e7a85a90c
>> a374ca1c394e219aa961#commitcomment-28894501
>>
>> @bitwiseman <https://github.com/bitwiseman> Discussion on plugin
>>> management was probably introduced in this JEP too early as we don't have a
>>> prototype for it (update center doesn't even have the required metadata)
>>> Would it make sense to revert this commit so we can follow-up with JCasC
>>> as an approved JEP, and prepare another JEP about plugin management (which
>>> would apply to docker images and probably few other use-cases) ?
>>
>>
>> I figured I'd respond here rather than buried in GH comments.
>>
>> Nicolas,
>> To be clear:  I'm not Reviewer for this JEP.   I set it back to this
>> "Draft" with the agreement of the sponsor as part of a clarification of the
>> JEP process.
>>
>
> Yes, that's why I asked you to revert this if we just want to get this
> discussion in a separate document.
>
>
>>
>> It sounds like Ewelina is working on further updates (including
>> incorporating the JOM feedback - yay!) and hasn't requested Review for
>> Acceptance yet.  As sponsor, when she believes the JEP meets the
>> requirements for Accepted status, I'm sure she'll request that it be
>> reviewed again.
>>
>
> ok, make sense as well.
>
>
>>
>> Ewelina,
>> Thanks for taking the time to incorporate feedback and to make sure
>> everyone is clear about the on-going status of the project.  I don't know
>> that I need to be involved in the maintainers meeting, but feel free to
>> send me an invite.
>>
>> -Liam
>>
>>
>>
>> On Tuesday, May 8, 2018 at 3:34:28 AM UTC-7, Ewelina Wilkosz wrote:
>>>
>>> just a short update - JEP update in progress, next week we're planning a
>>> short maintainers status meeting where I hope to clarify stuff and PR will
>>> be sent
>>>
>>> On Thursday, May 3, 2018 at 12:24:07 AM UTC+2, Jesse Glick wrote:
>>>>
>>>> On Wed, May 2, 2018 at 3:58 PM, Ewelina Wilkosz 
>>>> wrote:
>>>> > Any of you interested in contributing to that one? Please let me
>>>> know, so we
>>>> > don't duplicate
>>>>
>>>> I will leave the reasoning to you! Just bringing up things that seemed
>>>> to merit discussion.
>>>>
>>> --
>> 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/ms
>> gid/jenkinsci-dev/56c5a171-f7ed-4f53-bd67-c79bb182bb91%40googlegroups.com
>> <https://groups.google.com/d/msgid

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

I've added a section on this topic in JEP-201:
https://github.com/jenkinsci/jep/tree/master/jep/201#versioning

We can already generate a json-schema you can use to validate your yaml
file(s) before applying configuration.
What you miss is a tool to convert jenkins-core + plugins.spec -> json
schema.
This is something we could package as well (something comparable to
jenkinsfile-runner) or even provide "as a service".

We could also get such a tool both generate a schema and validate your
config, as it seems there's not  (yet) so much text editors to support json
schema validation in yaml

Would this help ?

2018-05-15 20:19 GMT+02:00 R. Tyler Croy :

> (replies inline)
>
> On Tue, 15 May 2018, nicolas de loof wrote:
>
> > 2018-05-15 0:20 GMT+02:00 Liam Newman :
> >
> > >
> > > Putting all that aside (as that is not the original point of this
> thread),
> > > the original suggestion was to include a version field in the CasC
> YAML.
> > > You said it would not work because the version would have to take into
> > > account the core version and versions of all plugins, otherwise it
> might
> > > break. Does that mean the CasC YAML could break _any time_  I upgrade
> any
> > > component? Doesn't that rather defeats the purpose of CasC?
> > >
> >
> > Yes indeed. CasC doesn't have it's own model, everything is based on
> actual
> > java code discovery at runtime. So upgrading core or any plugin is
> changing
> > this model. CasC targets reproducibility and immutability use-cases. If
> you
> > want to upgrade anything you need to test it before.
>
>
> Testing of changes between plugin versions was something I had great
> difficulty
> with for Groovy-scripting-based configuration, which was much more common
> prior
> to Configuration as Code. Do you have suggestions for administrators such
> as
> myself on how I might validate that my configuration YAML is
> correct/applies
> between any core or plugin upgrades?
>
> This gets to the underlying concern I had in mind when starting this
> thread, as
> an administrator, how will I know that my configuration applies correctly
> between any core or plugin upgrades? My initial thought was
> schema-versioning,
> but I'm certainly open to other suggestions.
>
>
>
> 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/20180515181926.GB3395%40grape.lasagna.io.
> 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/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR128o41%3D3cU056g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

2018-05-15 0:20 GMT+02:00 Liam Newman :

> Nicolas,
>
> Moving things to a separate JEP makes sense is some cases but it doesn't
> sound like the works here.  The design choices that need to be made in
> relation to credentials CasC will effect the design of the JEP-201.  Many
> plugins could be done in later JEPs, but for concepts as key as Credentials
> they would at least need to be concurrent JEPs and would need to be owned
>

As I tried to explain, credentials-plugin support is already there, just
the syntax used by the configurator has been debated and this is really an
implementation detail. I would have a strong -1 to define the adopted
syntax in JEP-201. JEP-201 is here to define how we ensure this is feasible
(like for any other component) and for this purpose we don't need anything
special to be said about credentials plugin.

About "Credentials" in the sense of "secrets" we already have external
secret source support. This is a topic we could add some informations about.


>
> Putting all that aside (as that is not the original point of this thread),
> the original suggestion was to include a version field in the CasC YAML.
> You said it would not work because the version would have to take into
> account the core version and versions of all plugins, otherwise it might
> break. Does that mean the CasC YAML could break _any time_  I upgrade any
> component? Doesn't that rather defeats the purpose of CasC?
>

Yes indeed. CasC doesn't have it's own model, everything is based on actual
java code discovery at runtime. So upgrading core or any plugin is changing
this model. CasC targets reproducibility and immutability use-cases. If you
want to upgrade anything you need to test it before.


>
> If anything all this strengthens the argument for having at least a
> top-level version field that guarantees some level of compatibility
> (perhaps at Jenkins Core API level).  It further suggests that the CasC
> needs to include some guidance/structure for talking about CasC YAML
> changes.  "No glue code" sounds great from a code/plugin-developer
> perspective, but it is sounding more and more like a anti-feature from user
> perspective.
>

Sure, but then you need to write and maintain 1500 glue-code adapters. This
is something we don't want to. This always has been a key topic to drive
this effort. I'm sorry to ear this drawback wasn't clearer to you, was
pretty obvious to me. There's nothing like free lunch; and no model / glue
code means there's nothing we can parse as "v1.0" while we try to configure
"v2.0", so a version number wouldn't help here.



>
> For v1.0, I suppose one could argue that this is a needed design choice to
> ship in non-infinite time, but that doesn't mean it can be completely
> ignored.  Some thought will still need to be given to how to ease this pain
> or at least measure and clearly communicate how often breaks would have
> occurred in the last year if CasC had been around.
>

Hard to tell, but probably on a regular basis. At least any time a major
plugin did changed it's UI binding (DataBoundConstructor).


>
> -L.
>
>
>
>
>
>
>
>
> On Monday, May 14, 2018 at 8:22:53 AM UTC-7, Jesse Glick wrote:
>>
>> On Fri, May 11, 2018 at 5:44 PM, nicolas de loof
>>  wrote:
>> > Secret is already supported based on jenkins-core registered stapler
>> > converters.
>>
>> Yes; my point was only that due to the nature of secrets, JCasC needs
>> to support keeping the actual values separate from the main YAML file
>> somehow—whether via a generic variable interpolation system, or
>> symmetric encryption, etc. This is already part of the reference
>> implementation, which is good.
>>
>> >> JEP-201 is a new
>> >> feature, so its developers are responsible for designing and
>> >> implementing appropriate integrations with existing foundational
>> >> components of Jenkins.
>> >
>> > I strongly disagree with this. From my perspective JEP-201 is about
>> generic
>> > mechanism to support configuration-as-code without glue code and option
>> for
>> > custom adapters where required.
>>
>> Yes, that is fine.
>>
>> > Maybe this should be discussed in a subsequent JEP if you consider this
>> > _that_ important.
>>
>> Perhaps, but my perspective is that a JEP should be reasonably
>> self-contained and define enough detail to implement an MVP, which
>> would certainly include support for credentials. If you defer this
>> aspect to an unspecified future JEP then there is a risk that this
>> planning either gets dropped, or tha

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

yes indeed.
But I also would like this specific seed-job support to move to job-dsl
plugin, so the way this configuration element is used is directly managed
by job-dsl plugin version


2018-05-13 1:36 GMT+02:00 Daniel Beck :

>
> > On 11. May 2018, at 17:14, nicolas de loof 
> wrote:
> >
> > I don't get your point
> >
> > the physical layout of the yaml file is directly built based on
> component discovery
> > YAML attributes are mapped to `Describable`s and other components based
> on how we can access them from root "jenkins" object (and other root
> elements). This mapping is not defined by CasC but by discovery from live
> jenkins instance model.
> >
> > i.e we discover "jenkins" has a "securityRealm" attribute and some
> implementation can be used to set this attribute. This directly defines the
> yaml tree. But the codebase has no reference to this structure.
>
> Some stuff is still defined by CasC, otherwise
> https://github.com/jenkinsci/configuration-as-code-plugin/pull/62
> wouldn't exist.
>
> --
> 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/38388CD1-DF9E-4DB9-B22E-B4A0F47ACC8D%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/CANMVJz%3D6kGMkft8KUUp9d9t2zL%3DbArQkfFJgdSz25-d0VWfODw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

Let me try to convince you with a comparison :

Pipeline is a central piece of Jenkins, and support for Git SCM in this
context is a MUST HAVE. In early days "git" DSL step was actually
implemented in pipeline plugin, but this later has been moved to
git-plugin, where it perfectly make sense, so that design changes in
git-plugin can be applied to "git" step in sync, and pipeline plugin just
becomes a backbone for other steps (so the large amount of pipeline-*-steps
plugins.

I'd like configuration-as-code to use the same approach : only provide the
backbone for configuration support, then have everything specific to a
plugin moved to target codebase, where it can be managed in sync.

2018-05-11 23:44 GMT+02:00 nicolas de loof :

>
>
> 2018-05-11 23:02 GMT+02:00 Jesse Glick :
>
>> On Fri, May 11, 2018 at 3:33 PM, nicolas de loof
>>  wrote:
>> > the exposed yaml model to
>> > configure credentials should be defined as part of credential plugin,
>> not by
>> > me within configuration-as-code.
>>
>> Well. JCasC likely needs some special handling for `Secret`, which
>> `credentials` uses for the actual secrets inside. Beyond that, I agree
>> that it makes sense for the specialized binding to ultimately live in
>> `credentials-plugin`.
>>
>
> Secret is already supported based on jenkins-core registered stapler
> converters.
>
>
>>
>> But I take issue with two ways this was framed. First of all, there is
>> nothing wrong with the design of credentials storage; it is sensible
>> given the expected usage model. JCasC makes it easy to autobind
>> configuration that lives all in one configuration screen. In this
>> case, the UI is divided into different screens with a specialized UI,
>> so specialized binding would be needed.
>>
>
> CasC is designed to manage data as a tree, which jenkins UI use to adopt.
> But not credentials-plugin relying on Maps and singletons.
>
>
>>
>> Second, yes it needs to be defined “by you” (well, by whomever is
>> striving to get JEP-201 accepted). Credentials are central to Jenkins
>> setup and a critical use case for JEP-201. And JEP-201 is a new
>> feature, so its developers are responsible for designing and
>> implementing appropriate integrations with existing foundational
>> components of Jenkins.
>>
>
> I strongly disagree with this. From my perspective JEP-201 is about
> generic mechanism to support configuration-as-code without glue code and
> option for custom adapters where required. Credentials is for sure a
> central piece of Jenkins, like pipeline is, or arguably many other plugins.
> But it's not JEP-201 to define how those should be exposed as a
> configurable data model. Maybe this should be discussed in a subsequent JEP
> if you consider this _that_ important. From my point of view this could be
> addressed within credentials plugin taking the decision on the model it
> want to expose and provide the required glue-code.
>
>
>>
>> --
>> 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/ms
>> gid/jenkinsci-dev/CANfRfr0eorvLJovVf9Fbut-zt0F9zDSvF_
>> v0qa0ZsUrrz%2BoNAg%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/CANMVJzm%3DYi3t%3DauTxD076fuqGJBzndf6ZCYnvz_bP-rkZFntgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

2018-05-11 23:02 GMT+02:00 Jesse Glick :

> On Fri, May 11, 2018 at 3:33 PM, nicolas de loof
>  wrote:
> > the exposed yaml model to
> > configure credentials should be defined as part of credential plugin,
> not by
> > me within configuration-as-code.
>
> Well. JCasC likely needs some special handling for `Secret`, which
> `credentials` uses for the actual secrets inside. Beyond that, I agree
> that it makes sense for the specialized binding to ultimately live in
> `credentials-plugin`.
>

Secret is already supported based on jenkins-core registered stapler
converters.


>
> But I take issue with two ways this was framed. First of all, there is
> nothing wrong with the design of credentials storage; it is sensible
> given the expected usage model. JCasC makes it easy to autobind
> configuration that lives all in one configuration screen. In this
> case, the UI is divided into different screens with a specialized UI,
> so specialized binding would be needed.
>

CasC is designed to manage data as a tree, which jenkins UI use to adopt.
But not credentials-plugin relying on Maps and singletons.


>
> Second, yes it needs to be defined “by you” (well, by whomever is
> striving to get JEP-201 accepted). Credentials are central to Jenkins
> setup and a critical use case for JEP-201. And JEP-201 is a new
> feature, so its developers are responsible for designing and
> implementing appropriate integrations with existing foundational
> components of Jenkins.
>

I strongly disagree with this. From my perspective JEP-201 is about generic
mechanism to support configuration-as-code without glue code and option for
custom adapters where required. Credentials is for sure a central piece of
Jenkins, like pipeline is, or arguably many other plugins. But it's not
JEP-201 to define how those should be exposed as a configurable data model.
Maybe this should be discussed in a subsequent JEP if you consider this
_that_ important. From my point of view this could be addressed within
credentials plugin taking the decision on the model it want to expose and
provide the required glue-code.


>
> --
> 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/CANfRfr0eorvLJovVf9Fbut-zt0F9zDSvF_v0qa0ZsUrrz%2BoNAg%
> 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/CANMVJzk5ZoqFYbV4HgK1k5FahDUe9EHF3V2wQODtQKfEOZ33CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

you get it wrong : what I'm saying is that the exposed yaml model to
configure credentials should be defined as part of credential plugin, not
by me within configuration-as-code. The existing code is there to
demonstrate we _can_ support credentials despite it's weird design (!) with
some reasonable code, but actual credentials support is under
credentials-plugin responsibility (also to consider this should follow
credentials-plugin version, not configuration-as-code release cycles)

2018-05-11 21:23 GMT+02:00 Stephen Connolly :

>
> On Fri 11 May 2018 at 17:32, Jesse Glick  wrote:
>
>> On Fri, May 11, 2018 at 11:14 AM, nicolas de loof
>>  wrote:
>> > we discover "jenkins" has a "securityRealm" attribute and some
>> > implementation can be used to set this attribute. This directly defines
>> the
>> > yaml tree. But the codebase has no reference to this structure.
>>
>> Right. So, again, the version would not be referring to the existence
>> or semantics of a `securityRealm` attribute. It would be referring to
>> the logic that governs how the `Jenkins.getSecurityRealm()` method is
>> mapped to a YAML attribute of that name, and how a particular
>> `SecurityRealm` subtype is identified in its value. Now the case of
>> the attribute name is pretty simple, of course—JavaBeans naming
>> convention—but there can be more subtle cases: handling of symbol
>> annotations or lack of them (which already comes up in the handling of
>> `ldap` in this example!), collection types, getter/setter/constructor
>> type mismatches, handling of secrets¹, convenience aliases, deprecated
>> members, and so on.
>>
>> Experience with the `structs` plugin and its binding to Pipeline
>> Script in `workflow-cps` indicates that there are plenty of hard
>> problems to solve and it is not uncommon for the surface syntax to
>> need to be changed in response. For Pipeline (talking about Scripted
>> now) we never had a formal “language version” or anything like that,
>> which has caused plenty of headaches trying to maintain compatibility
>> with old scripts. I think JCasC will hit analogous issues.
>>
>>
>> ¹Whenever that is actually formalized. As it needs to be, IMO, for
>> 1.0—you cannot just say that the Credentials plugin maintainer is
>> going to solve this for you.
>
>
> Yeah, I advise against relying on me to fix schema version problems for
> you :-P
>
>>
>>
>> --
>> 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/CANfRfr23zwVvy3RQxD7F_POsgDZxMtSt2vgM%3DGugGF913RTS%
>> 2Bw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins 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/CA%2BnPnMwB%2BBCH2M5GiyfLiudpx%
> 2Biaxchq7ZzbFi5hCeGccKuPBA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwB%2BBCH2M5GiyfLiudpx%2Biaxchq7ZzbFi5hCeGccKuPBA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJz%3DfvStFRYJVGJYF19J56BYF2GQhDVfmXbtxz26qi40H1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

I don't get your point

the physical layout of the yaml file is directly built based on component
discovery
YAML attributes are mapped to `Describable`s and other components based on
how we can access them from root "jenkins" object (and other root
elements). This mapping is not defined by CasC but by discovery from live
jenkins instance model.

i.e we discover "jenkins" has a "securityRealm" attribute and some
implementation can be used to set this attribute. This directly defines the
yaml tree. But the codebase has no reference to this structure.

2018-05-11 17:05 GMT+02:00 Jesse Glick :

> On Fri, May 11, 2018 at 3:29 AM, nicolas de loof
>  wrote:
> > configuration-as-code schema depends on jenkins-core version and all
> plugins
> > version being installed. So generating a "version" would be hard.
>
> I think you are mixing up two things. One is the physical layout of
> the config file and how various YAML attributes are mapped to
> `Describable`s and that sort of thing, which is not likely to change
> frequently, but might. That deserves a version number.
>
> The other thing is the concrete list of identifiers available in your
> system, which of course will vary depending on the versions of
> components.
>
> --
> 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/CANfRfr111z%2BNFBAnHQFT%2BFELRsNWU5-
> j2OB1XemUwu6JpLVjKA%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/CANMVJznEOzzj6AGwuCiud_BsiFeEKuJDMDwjzentdT9zmkNDdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

To get more into details :

docker-compose has it's own data model and translates into docker API
calls. Doing so it can support model versions for config file, as well as
adapt when required to underlying docker API Changes

configuration-as-code has been designed as a "no glue code" model : we
don't write a single line of code for configuration attribute of plugin X
to be supported, everything is based on runtime discovery by reflexion.
This design allows to support (mostly) all plugins out-of-the-box, but the
price to pay is that there's no "model" but the one discovered at runtime :
if you upgrade a plugin which refactored it's databound "API" then the
configuraiton schema will change as well.

In some "as-code" process we expect such upgrade would be tested before
being pushed to production master, so that model changes would be detected
before. CasC do already report unknown attributes and fail fast. But afaik
there's nothing much we can offer here.

2018-05-11 9:29 GMT+02:00 nicolas de loof :

> not so simple :
>
> configuration-as-code schema depends on jenkins-core version and all
> plugins version being installed. So generating a "version" would be hard.
> Credentials syntax used in alpha is here for demonstration purpose, with
> minimal lines of code to provide this feature, I expect we remove this code
> from CasC as we release 1.0 so it can be implemented by credentials plugin
> its own way.
>
> 2018-05-10 22:30 GMT+02:00 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/ms
>> gid/jenkinsci-dev/CANfRfr1ARV%2Br1u98umpjCZBvd2%3Dh7msQ1TQFT
>> UvbhpoGPc%3Dz6g%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/CANMVJz%3DOUswr3u4U07zQeFQn6fTJXPUn9A17fdGyV4dE4whQTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

not so simple :

configuration-as-code schema depends on jenkins-core version and all
plugins version being installed. So generating a "version" would be hard.
Credentials syntax used in alpha is here for demonstration purpose, with
minimal lines of code to provide this feature, I expect we remove this code
from CasC as we release 1.0 so it can be implemented by credentials plugin
its own way.

2018-05-10 22:30 GMT+02:00 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.
>

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

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[nicolas de loof]

2018-05-08 21:08 GMT+02:00 Liam Newman :

>
> Just FYI: Nicolas asked a question of me in a GH comment:
> https://github.com/jenkinsci/jep/commit/78bede6c731e7a85a90ca374ca1c39
> 4e219aa961#commitcomment-28894501
>
> @bitwiseman  Discussion on plugin
>> management was probably introduced in this JEP too early as we don't have a
>> prototype for it (update center doesn't even have the required metadata)
>> Would it make sense to revert this commit so we can follow-up with JCasC
>> as an approved JEP, and prepare another JEP about plugin management (which
>> would apply to docker images and probably few other use-cases) ?
>
>
> I figured I'd respond here rather than buried in GH comments.
>
> Nicolas,
> To be clear:  I'm not Reviewer for this JEP.   I set it back to this
> "Draft" with the agreement of the sponsor as part of a clarification of the
> JEP process.
>

Yes, that's why I asked you to revert this if we just want to get this
discussion in a separate document.


>
> It sounds like Ewelina is working on further updates (including
> incorporating the JOM feedback - yay!) and hasn't requested Review for
> Acceptance yet.  As sponsor, when she believes the JEP meets the
> requirements for Accepted status, I'm sure she'll request that it be
> reviewed again.
>

ok, make sense as well.


>
> Ewelina,
> Thanks for taking the time to incorporate feedback and to make sure
> everyone is clear about the on-going status of the project.  I don't know
> that I need to be involved in the maintainers meeting, but feel free to
> send me an invite.
>
> -Liam
>
>
>
> On Tuesday, May 8, 2018 at 3:34:28 AM UTC-7, Ewelina Wilkosz wrote:
>>
>> just a short update - JEP update in progress, next week we're planning a
>> short maintainers status meeting where I hope to clarify stuff and PR will
>> be sent
>>
>> On Thursday, May 3, 2018 at 12:24:07 AM UTC+2, Jesse Glick wrote:
>>>
>>> On Wed, May 2, 2018 at 3:58 PM, Ewelina Wilkosz 
>>> wrote:
>>> > Any of you interested in contributing to that one? Please let me know,
>>> so we
>>> > don't duplicate
>>>
>>> I will leave the reasoning to you! Just bringing up things that seemed
>>> to merit discussion.
>>>
>> --
> 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/56c5a171-f7ed-4f53-bd67-c79bb182bb91%
> 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/CANMVJzmqJkNe3AJV%3DuQ5cyZSMWhhieeUcAXEmxUj5-c6w1w5qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkinsfile-runner + Configuration-as-Code

[nicolas de loof]

2018-05-01 14:59 GMT+02:00 Jesse Glick :

> On Sat, Apr 28, 2018 at 2:46 AM, nicolas de loof
>  wrote:
> >> you still have all
> >> the drawbacks of a build expressed in a weird DSL,
> >
> > Not my fault.
>
> Obviously not; half mine. :-) My point is that the approach you are
> describing does not do anything to help resolve that. Whereas we *do*
> have some ideas for running the script out of process, which solves
> the DSL/sandbox issues, and should not require drastic changes to the
> overall user experience.
>
> >> you have the
> >> serious functional limitations of tools like Build Publisher
> >
> > Which in future I expect not to be required as build status, artifacts,
> > logs... would be stored on some cloud-native storage and directly
> accessible
> > without Jenkins in the middle to serve them.
>
> Definitely we plan for that. This is not what I was talking about.
> There is a gigantic long tail of Jenkins features (mostly plugins)
> which would not work in a Build Publisher-like environment; some of
> that could be fixed with a lot of labor, some probably not at all
> short of a total redesign.
>

Not sure what you have in mind (if you have a concrete sample this could
help).
I can't imagine a plugin that couldn't work with a rsync-copy of a remote
build dir.
But I might miss something.

Anyway what I'd like to achieve is to fully remove Jenkins Web UI and only
rely on Github commit status
for user interaction (read more on http://bit.ly/blind-jenkins). So plugins
would only make sense
during the build, and any UI contributing plugin would just be excluded.


>
> > 'stages' still make some sense for those interested in visualization
> > or to spilt a huge build log into more focused sections.
>
> Yes; independently of all this discussion, I would love to see Blue
> Ocean support something like the Collapsing Console Sections plugin,
> so you would not be forced to “escape” from your native build process
> into Pipeline script merely to demarcate (at least linear) stage
> boundaries. For example,
>
> https://github.com/jenkinsci/docker-workflow-plugin/pull/105
>
> could have collapsed four scripts into one, making the Pipeline script
> considerably shorter (and the master load correspondingly a bit
> lighter).
>

+1
I'd like pipeline stages to be controlled from shell scripts, something
like :
echo "entering stage foo" > /var/run/jenkins.sock
so I could rename my pipeline scripts as "Jenkinsfile.sh"


> > probably not such
> > a trivial think to implement and alternative workflow executor to replace
> > CPS with a plain groovy runtime, is it ?
>
> Not trivial at all, but I believe feasible.
>

ok, then when this becomes available we would be able to make
jenkinsfile-runner way simpler :D


>
> --
> 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/CANfRfr1eqa2a-9dzBkCwGibVgqyPHsb%
> 2BGwxY0rJ3BmZU4eLCmw%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/CANMVJzkEUkisKE8RH66ASDuJHe%3DOMdawS1cOQRJFJ9jSSFLHRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkinsfile-runner + Configuration-as-Code

[nicolas de loof]

I indeed think a JEP would make sense for jenkinsfile-runner, to describe
how it interacts with other projects.
This is the next step imho.
This thread is more about brainstorming about some use-cases and check for
interest about this.

2018-04-28 11:05 GMT+02:00 Ewelina Wilkosz :

> I am pretty sure you'll make many people happy with it - are you planning
> to write/is there already a JEP for that?
> since you've mentioned JCasC couple of times I believe it would make sense
> to how exactly those two could work together (I'm assuming you have some
> ideas in mind, but we can try to have it somewhere else also :) )
>
> On Saturday, April 28, 2018 at 8:46:18 AM UTC+2, nicolas de loof wrote:
>>
>>
>>
>> Le ven. 27 avr. 2018 à 15:46, Jesse Glick  a
>> écrit :
>>
>>> On Fri, Apr 27, 2018 at 3:52 AM, nicolas de loof
>>>  wrote:
>>> > jenkinsfile-runner --config jenkins-dev.yaml
>>>
>>> This sounds useful.
>>>
>>> > I also have in mind another possible usage : one-shot jenkins masters -
>>> > let's call this "serverless jenkins" for the buzzword.
>>> >
>>> > To avoid huge jenkins masters running thousand pipelines, we could
>>> rely on
>>> > jenkinsfile-runner for pipeline execution, a front-end master being
>>> used for
>>> > job configuration and web UI only. As a git event comes to jenkins
>>> > infrastructure, a new serverless payload would be triggered (think :
>>> docker
>>> > container running somewhere) to execute jenkinsfile-runner with
>>> adequate
>>> > jenkins.yaml, so pipeline can run the same as if the front-end master
>>> had
>>> > ran it by itself.
>>> > […]
>>> > On pipeline completion, jenkinsfile-runner would then publish the build
>>> > status on front-end master (something comparable to
>>> buildpublisher-plugin).
>>>
>>> This makes little sense to me. You still have the huge Jenkins master
>>> rendering a web UI for thousands of pipelines,
>>>
>>
>> Right. Let's now consider this fronted is _not_ Jenkins but some UI which
>> can expose build status ? Or maybe even no UI but just a GitHub commit
>> status update ?
>>
>>
>> and you still have all
>>> the drawbacks of a build expressed in a weird DSL,
>>
>>
>> Not my fault. Use of groovy for build-flow was a mistake. We should have
>> learned from this initial "draft".
>>
>> plus you have the
>>> serious functional limitations of tools like Build Publisher,
>>
>>
>> Which in future I expect not to be required as build status, artifacts,
>> logs... would be stored on some cloud-native storage and directly
>> accessible without Jenkins in the middle to serve them.
>>
>> plus you
>>> have to set up a bunch of infrastructure to make the “one-shot” master
>>> be able to provision or link to build agents
>>
>>
>> Right. Let's say we only support docker agents, and a descent plugin able
>> to create such nodes (an idea I'd like to investigate is to have labels ==
>> docker image)
>>
>> —unless it requires only
>>> one node and no real interaction with anything else in the system, in
>>> which case your Pipeline would better have been expressed as
>>>
>>> node {
>>>   sh '. /thisjob/run.sh'
>>> }
>>>
>>
>> Isn't this the sole reasonable Jenkinsfile one should write ? Kidding
>> appart, 'stages' still make some sense for those interested in
>> visualization or to spilt a huge build log into more focused sections. For
>> anything else I agree a shell script is the best tool we have. (I wonder we
>> named this "Jenkinsfile" and not "makefile" ;-) )
>>
>>
>>
>>> with the script and credentials coming from Kubernetes and there is no
>>> need for any special runner.
>>>
>>> As to avoiding Groovy sandboxing, this is best done in a different
>>> way: by not using `workflow-cps`, and rather running the script in a
>>> separate plain-Groovy process (yes, “serverless”) connecting to the
>>> master for step implementations. Simpler, and far easier to migrate to
>>> from existing configurations.
>>>
>>
>> This sounds what I expected Jenkinsfile-runner to be, but probably not
>> such a trivial think to implement and alternative workflow executor to
>> replace CPS with a plain groovy run

Re: Jenkinsfile-runner + Configuration-as-Code

[nicolas de loof]

Le ven. 27 avr. 2018 à 15:46, Jesse Glick  a écrit :

> On Fri, Apr 27, 2018 at 3:52 AM, nicolas de loof
>  wrote:
> > jenkinsfile-runner --config jenkins-dev.yaml
>
> This sounds useful.
>
> > I also have in mind another possible usage : one-shot jenkins masters -
> > let's call this "serverless jenkins" for the buzzword.
> >
> > To avoid huge jenkins masters running thousand pipelines, we could rely
> on
> > jenkinsfile-runner for pipeline execution, a front-end master being used
> for
> > job configuration and web UI only. As a git event comes to jenkins
> > infrastructure, a new serverless payload would be triggered (think :
> docker
> > container running somewhere) to execute jenkinsfile-runner with adequate
> > jenkins.yaml, so pipeline can run the same as if the front-end master had
> > ran it by itself.
> > […]
> > On pipeline completion, jenkinsfile-runner would then publish the build
> > status on front-end master (something comparable to
> buildpublisher-plugin).
>
> This makes little sense to me. You still have the huge Jenkins master
> rendering a web UI for thousands of pipelines,


Right. Let's now consider this fronted is _not_ Jenkins but some UI which
can expose build status ? Or maybe even no UI but just a GitHub commit
status update ?


and you still have all
> the drawbacks of a build expressed in a weird DSL,


Not my fault. Use of groovy for build-flow was a mistake. We should have
learned from this initial "draft".

plus you have the
> serious functional limitations of tools like Build Publisher,


Which in future I expect not to be required as build status, artifacts,
logs... would be stored on some cloud-native storage and directly
accessible without Jenkins in the middle to serve them.

plus you
> have to set up a bunch of infrastructure to make the “one-shot” master
> be able to provision or link to build agents


Right. Let's say we only support docker agents, and a descent plugin able
to create such nodes (an idea I'd like to investigate is to have labels ==
docker image)

—unless it requires only
> one node and no real interaction with anything else in the system, in
> which case your Pipeline would better have been expressed as
>
> node {
>   sh '. /thisjob/run.sh'
> }
>

Isn't this the sole reasonable Jenkinsfile one should write ? Kidding
appart, 'stages' still make some sense for those interested in
visualization or to spilt a huge build log into more focused sections. For
anything else I agree a shell script is the best tool we have. (I wonder we
named this "Jenkinsfile" and not "makefile" ;-) )



> with the script and credentials coming from Kubernetes and there is no
> need for any special runner.
>
> As to avoiding Groovy sandboxing, this is best done in a different
> way: by not using `workflow-cps`, and rather running the script in a
> separate plain-Groovy process (yes, “serverless”) connecting to the
> master for step implementations. Simpler, and far easier to migrate to
> from existing configurations.
>

This sounds what I expected Jenkinsfile-runner to be, but probably not such
a trivial think to implement and alternative workflow executor to replace
CPS with a plain groovy runtime, is it ?


> --
> 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/CANfRfr37wA%3DQUC5GTSBy4AgSFocM%3DD7NFFjsYyvYqgF9WNB71w%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/CANMVJznHiw%3DGsF-2DPb6PmaDxBybH%3DXoSzqZMZpgDQZxvspGbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jenkinsfile-runner + Configuration-as-Code

[nicolas de loof]

Hello there,

I'm working on Jenkinsfile-runner
 investigating possible
use-cases. A major point I've noticed with this promising tool is that most
Pipeline scripts will require some initial master setup (credentials,
variables, node labels, tools, etc) so are not strictly portable. On the
other hand, having worked on the Configuration-as-Code projet, I know a
simple way to setup a jenkins master in a predictable and reproducible
state. I'd like to combine both.

As a result, one could store in SCM

   - a Jenkinsfile to define the pipeline execution steps
   - a jenkins.yaml file to define the required master setup
   - a plugin.txt file to define the set of plugins required to run this
   pipeline (more on this later)

I think this could be a nice driver for JCasC to embrace some extra
use-cases, typically: how to smoothly integrate with a developer's workflow
to *run arbitrary pipeline locally*.

Part of this use-case is the ability to dry-run a pipeline
, which is a
larger topic than just jenkinsfile-runner, but the later could be part of
this story. Typically, it could offer simple ways to switch environment /
credentials so that pipeline runs with test resources, and not production
ones. Typically, I would expect we can run something like this :

jenkinsfile-runner --config jenkins-dev.yaml

Doing so would setup the headless jenkins master with development-only
credentials, and environment variables to rely on test resources (a local
web server as deployment target for sample), while the actual CI/CD master
would run the same on production infrastructure.


I also have in mind another possible usage : *one-shot jenkins masters* -
let's call this "serverless jenkins
" for the buzzword.

To avoid huge jenkins masters running thousand pipelines, we could rely on
jenkinsfile-runner for pipeline execution, a front-end master being used
for job configuration and web UI only. As a git event comes to jenkins
infrastructure, a new serverless payload would be triggered (think : docker
container running somewhere) to execute jenkinsfile-runner with adequate
jenkins.yaml, so pipeline can run the same as if the front-end master had
ran it by itself.

This jenkins.yaml could be generated directly from master (this isn't yet
implemented in JCasC, but definitively in the roadmap
) with
the benefit it could be scoped to target job : this jenkins.yaml would only
include credentials and other resources your job legitimately have access
to, then when injected in transient, headless, jenkinsfile-runner's master,
you gain physical security and can relax Pipeline's sandboxing.

On pipeline completion, jenkinsfile-runner would then publish the build
status on front-end master (something comparable to buildpublisher-plugin).


About *plugins management*, we want this to be fully part of JCasC, and I
have a pending PR
 on
this topic. From JCasC this is a chicken-egg  issue, ad JCasC itself is a
jenkins plugin. From jenkinsfile-runner this is way simpler to implement :
as the setup take place before the headless master init sequence starts, we
can download and install various plugins.

As an initial state I've introduced support for plugins.txt file (the same
one supported by jenkins official docker image
). Storing such a plugins list in
SCM will let jenkinsfile-runner install the adequate plugins set on
headless master to run the pipeline. Major drawback is this only supports
standard update center as plugin source. A tighter integration with JCasC
could be used to parse the plugins section from yaml configuration and get
plugins from any update sites with  adequate proxy settings.


So, many challenges to address and potential extension for those tools. For
me to get into the right direction, I would welcome any feedback, either on
this thread or on github issues.

-- 
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/CANMVJz%3D1t%3Du7v-T7tj3CypX5igdnen%2B%2BBvMEuBwmhOZQ5JTAFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[nicolas de loof]

2018-04-18 0:42 GMT+02:00 Jesse Glick :

> On Tue, Apr 17, 2018 at 4:45 PM, nicolas de loof
>  wrote:
> > Job class hierarchy is full of hand written JSON parsing
>
> I suspect such cases are fixable, which would take some work, but on
> the other hand we would get a clearer code base as a result anyway.
>

Sure, but this will be for future version then
We want JCasC to support current releases of Jenkins by Praqma customers
(and others), not require bleeding edge Jenkins core.


>
> --
> 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/CANfRfr03rVj6r1tWfwYeO1QKeDMtDYjuc8fF0Se%2B4Rh9qbZFvg%
> 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/CANMVJzn%3DSo9ZbOEifWiW8Oa3jkGJBRyk%3DbbRSNbhM%2B2qC38Shg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[nicolas de loof]

2018-04-17 22:05 GMT+02:00 Jesse Glick :

> On Tue, Apr 17, 2018 at 2:03 PM, nicolas de loof
>  wrote:
> > the yaml schema is for a specific version of jenkins-core + plugin.
> > Any change to a plugin will change this model, this will happen any time
> a
> > DataBoundConstructor is modified
>
> Well, typically we would expect parameters to be compatible after a
> plugin update, so that if for example a `@DataBoundSetter` method
> needs to be `@Deprecated`, it is removed from databinding but still
> accessible as a Java setter. The compatibility policy for such
> refactorings does need to be defined. Currently we only expect plugins
> to be compatible in their XStream settings form, plus Pipeline `Step`s
> and any `Describable`s used by them need to continue to accept
> parameters that worked before.
>

we exclude Deprecated setters as potential CasC attributes, so this
wouldn't help
As you said there's no expectation for compatibility at this level we could
rely on.
That being said I don't consider this to be an issue : with CasC we can
produce a schema and tooling to discover such compatibility issue and let
end-user know before they apply to production.


>
> > I would anyway expect Credentials plugin to own this code, so such
> decision
> > is made from maintainer
>
> JEP-201 is introducing a new overall Jenkins feature, and the
> Credentials plugin is a longstanding piece of plumbing, so I would
> expect JEP-201 developers to address this particular integration.
>

CasC plugin demonstrate we can support it with current implementation, even
if this one relies on some uncommon yaml syntax.
I consider credentials-plugin maintainer to have a better vision of what
should be exposed to end-user than me.



>
> > I don't understand why this plugin adopted this
> > odd design - most probably for compatibility reasons
>
> I do not think compatibility had anything to do with it. The
> configuration model of Credentials is that you have various providers,
> inside of each of which you can create various domains, each of which
> then contains a set of credentials. The Java-level structure is more
> or less arbitrary and was not intended to map directly to Jenkins
> databinding, because its UI manifestation is not a single
> configuration screen.
>
> > sounds to me job-dsl could support a yaml syntax (just by switching
> > parser)
>
> Why would you need `job-dsl` at all? You already have a general system
> for binding YAML to `Describable`s. You would need a bit of extra code
> to bind some syntax to `TopLevelItem` and
> `DirectlyModifiableTopLevelItemGroup`, and a call to JENKINS-50173 if
> and when written.
>

1. Job class hierarchy is full of hand written JSON parsing so we can't use
same discovery approach
2. job-dsl is very popular for this purpose, I don't want to spend time
re-inventing the wheel for a successful solution.

I'd like job-dsl support to be option in JCasC, so we do support this
approach but some alternate way is also possible in a future release.


> --
> 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/CANfRfr00%2BpNy%2BSfbY%2BLeye-GYd0v7Q%
> 2BxttRZCJddyv_Y8fgOyA%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/CANMVJzn%3Dx0bUXrqPECiFLo-5Fpd3PkVxwVcm%2BvnDBPbNDg%3DDYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JEP-201] [configuration-as-code] Feedback from Meetup

[nicolas de loof]

2018-04-17 17:58 GMT+02:00 Jesse Glick :

> Some things that might otherwise have gotten lost in IRC.
>
>
> About the automatic inference of symbols like `ldap` from
> `hudson.security.LDAPSecurityRealm`: this seems like a nice trick to
> use when prototyping the JEP, so you can see realistic stuff working
> before plugins are updated to use `@Symbol`. But I do not think this
> should be retained in a 1.0 version—all supported plugins should be
> given the annotation. Reasoning:
>
> · Adding an annotation poses no risk to plugin stability, so there is
> no reason for a maintainer to object to it.
> · Symbols must be unique within their extension point (for example
> there may be only one `SecurityRealm` named `ldap`), so they must be
> chosen carefully and deliberately.
> · People might begin relying on the inferred names and then it would
> be a compatibility issue to fix this later.
>
>
the yaml schema is for a specific version of jenkins-core + plugin.
Any change to a plugin will change this model, this will happen any time a
DataBoundConstructor is modified, this is the price to pay for allignment
with UI databinding.
As a result, I don't think we should expect any compatibility on version
upgrades. If you want to run with new version of plugins, run a test master
or any JCasC validation tool before.


>
> The credentials domain syntax, IIRC something like
>
> system:
>   ? # global
>   : -credentials
> # …
>
> baffles everyone who sees it. Just because internally `credentials`
> uses a `Map` from (I guess) domains to lists of credentials does not
> mean you must reflect that in YAML syntax. You should rather model a
> list of credentials, each of which may have an optional attribute for
> the domain (ID?).
>

The idea here was to estimate the minimal required code base to offer glue
code for credentials. This is definitively not for 1.0
I would anyway expect Credentials plugin to own this code, so such decision
is made from maintainer - I don't understand why this plugin adopted this
odd design - most probably for compatibility reasons - the web UI offering
a hierarchical representation of registered credentials.


>
> It is no excuse that you are trying to keep things mapped tightly to
> the databinding model in the plugin, because Jenkins databinding does
> not have any standard support for `Map`s at all—this is all bound to
> custom UI screens in `credentials`. Therefore it is reasonable for
> JCasC to also have a custom converter. Plugins which use simple
> databinding, which would consist of `List`s of `Describable`s only,
> would not need any custom code.
>

As I said, I expect such things to take place within plugins themsleves,
either with custom JCasC _or_ by changing the databound model


>
>
> Using Job DSL Groovy to create jobs is fine as a short-term workaround
> but should not be how `TopLevelItem`s are defined in 1.0 I think.
> There should be native YAML syntax for this, based on the same
> databinding model as any other settings. As `@Symbol` is adopted,
> these should look structurally similar anyway.
>

Agree, sounds to me job-dsl could support a yaml syntax (just by switching
parser). Need to investigate how to generate the adequate schema and
documentation



>
> --
> 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/CANfRfr3e56PQf4vrDLPjPU11MxzKX
> 3L%3DR%2BQVROgyAyuKRYB97A%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/CANMVJznHMAPGtfava_DgxpNKgLGsEsWfAGgUiuPbNMRA3wbxfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Asking for commiter access to amazon-ecs-plugin

[nicolas de loof]

My +1 here

@Daniel can you proceed 
with https://issues.jenkins-ci.org/browse/INFRA-1501 ?

Le jeudi 15 février 2018 14:04:40 UTC+1, Carlos Sanchez a écrit :
>
> Created https://issues.jenkins-ci.org/browse/INFRA-1501 to follow
>
> On Thursday, January 4, 2018 at 6:51:18 PM UTC+1, Jordi Miguel wrote:
>>
>> Hi all,
>>
>> It's been more than one month since last message on this thread and we 
>> still don't see any progress to unblock development. I'm sure Jan made a 
>> good job while he was leading the plugin's development and we thank him for 
>> it. Unfortunately he doesn't seem to be active anymore so, can we give 
>> commit permissions to someone who's active? On previous messages looks like 
>> Douglas Manley was happy to take over the role and I suspect he has not 
>> changed his mind.
>> I don't care much who ends up being the new maintainer but we're 
>> approaching the year mark since the last commit that found its way to 
>> master's branch and there are plenty of PR's waiting for a merge that 
>> haven't succeed because we don't have anyone with write permissions in the 
>> active community.
>>
>> I hope we can find a solution to this issue soon. If there is anything I 
>> can do to help resolve problems please don't hesitate to ask.
>>
>>
>> Thanks,
>> Jordi
>>
>> El miércoles, 29 de noviembre de 2017, 21:39:40 (UTC+1), Yaramada Surya 
>> tej escribió:
>>>
>>> Hi Mathus,
>>>   It would be great if any one can change the maintainer 
>>> of this plugin to Douglas as he is willing to took it so that we can 
>>> utilize this plugin , many of us are waiting to get this pull request 
>>> merged.
>>>
>>>
>>> Thanks
>>> Surya
>>>
>>> On Thursday, 7 September 2017 17:33:57 UTC-4, Baptiste Mathus wrote:

 Hello,
 Seems like Jan is not active either these days or anymore at all.

 So either you can see if you want to adopt this plugin (in that case 
 please follow the process described on the wiki), or this is likely to 
 stay 
 this way until someone does I suspect.

 Baptiste

 Le 7 sept. 2017 17:22, "Surya yaramada`"  a écrit :

> Hi,
>  I am sorry for interrupting again but can I please know if there 
> is a chance to merge the pull requests for AMAZON-ECS plugin.
>
>
> Thanks 
> Surya
>
> On Thursday, August 24, 2017 at 4:12:47 PM UTC-4, Daniel Beck wrote:
>>
>>
>> > On 24. Aug 2017, at 22:09, Surya yaramada`  
>> wrote: 
>> > 
>> >  Can I get any updates on this? 
>> > 
>>
>> There's no need for multiple emails per day. Give him a week or so. 
>> Jan may well be on vacation. 
>>
>> -- 
> 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/4f569b34-cfb3-427f-adc3-40406f9c6b3e%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/0959ea7e-42ac-4010-be96-2fcc33378c25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Draft JEP: Configuration as Code

[nicolas de loof]

This slides deck is indeed expected to be used for JAM presentations
unfortunately it hasn't been used for a recorded session yet

2018-02-14 21:30 GMT+01:00 eric.smalling via Jenkins Developers <
jenkinsci-dev@googlegroups.com>:

> Saw all of the talk about this from the post-FOSDEM hackday work and I'm
> very interested in presenting about it at the DFW JAM this month.   The
> repo links to a slide deck presentation, are those slides up to date and
> something I might use for a JAM presentation?   If so, is there a recording
> of any talks they were used at that I could watch?
>
> Thanks,
> Eric S.
>
>
> On Tuesday, November 7, 2017 at 3:49:59 AM UTC-6, nicolas de loof wrote:
>>
>> Hi,
>>
>> Some of you who joined Contributor Summit at Jenkins World'17 already
>> know about the resurrecting effort to provide configuration-as-code for
>> Jenkins management (JENKINS-31094)
>>
>> Both Praqma and CloudBees have been investigating on this topic last
>> months, and have wrote prototypes to cover this need. As we learned about
>> each other effort we decided to join forces, and make this public as a JEP
>> proposal.
>>
>> Our joined prototype is here : https://github.com/jenkinsci
>> /configuration-as-code-plugin
>> We also wrote a document to explain our goals and design decisions. We
>> used JEP template
>> <https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/JEP.adoc>
>>  so
>> we can now propose this for JEP acceptance (I guess this is the right place
>> to do so)
>>
>> We'll be happy to hear from you about this.
>>
> --
> 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/5335be02-ae53-4e01-bb87-0088d3351b42%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/5335be02-ae53-4e01-bb87-0088d3351b42%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJznzO9maEP0_e1%3D%2BxxkaYF%2Bskte%3DxXZAUdq5ybNpONGgng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accelerating Jenkins development with Jenkins Essentials

[nicolas de loof]

ok, starting to get your point.

But then I wonder why you don't just get evergreen to be the process to
start jenkins and control it as a child process, so you don't need extra
supervisord

2018-02-14 21:06 GMT+01:00 R. Tyler Croy :

> (replies inline)
>
> On Wed, 14 Feb 2018, nicolas de loof wrote:
>
> > Something I don't get here is why you need an external evergreen-client
> to
> > manage updates, and can't just get this running from within Jenkins.
>
> This is covered under "Alternative Approaches" here:
> https://github.com/jenkinsci/jep/tree/master/jep/301#
> extending-jenkins-itself
>
> I think that section should help clarify things.
>
> > I also wonder how you manage jenkins.war version here, which is bundled
> in
> > the docker image vs upgrades. Does this mean the image comes with a
> default
> > jenkins.war but won't override when used on an existing JENKINS_HOME ?
> And
> > then upgrading and restarting service won't actually reflect a core
> upgrade
>
>
> This is similar to the point which Jesse brought up earlier in the thread,
> and
> the resolution which I am incorporating into JEP-301 is that
> jenkins/evergreen
> should be "small" and just have enough code inside the container to reach
> out
> to the Evergreen hosted service layer and ask for the latest (core +
> plugins)
> before starting Jenkins. Succintly put, this would mean jenkins/evergreen
> would
> not ship with a jenkins.war.
>
>
>
> Hope that helps
>
>
> Cheers
> - R. Tyler Croy
>
> --
>  Code: <https://github.com/rtyler>
>   Chatter: <https://twitter.com/agentdero>
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>
> --
> 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/20180214200627.qqocqne3gynh6msx%40blackberry.
> coupleofllamas.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/CANMVJzm1sPWAH_HbbnJThy-zE9Lja0av8yiHxh4Ws84g1zuMnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accelerating Jenkins development with Jenkins Essentials

[nicolas de loof]

Something I don't get here is why you need an external evergreen-client to
manage updates, and can't just get this running from within Jenkins.

I also wonder how you manage jenkins.war version here, which is bundled in
the docker image vs upgrades. Does this mean the image comes with a default
jenkins.war but won't override when used on an existing JENKINS_HOME ? And
then upgrading and restarting service won't actually reflect a core upgrade
?



2018-02-14 19:26 GMT+01:00 R. Tyler Croy :

> (replies inline)
>
> On Wed, 14 Feb 2018, nicolas de loof wrote:
>
> >
> > I haven't found any references to supervisord in JEP pull request,
> neither
> > about kubernetes - did I miss something ?
> > Anyway I tend to agree with this comment about packaging supervisord with
> > jenkins essential within a docker image as a bad practice. I don't think
> > this has anything to relate to running this as plain docker or with some
> > orchestrator, this just makes the docker image a mutable instance, which
> > should be avoided. Without much details on where this discussion comes
> from
> > I can't really tell much about alternatives.
>
>
> Surya was referring to the second document in this thread which I sent out:
> https://github.com/jenkinsci/jep/tree/master/jep/301
>
>
> I understand the "bad practice" argument against this approach but I
> haven't
> yet seen a counter-proposal which accomplishes what jenkins/evergreen
> needs to
> accomplish, without using supervisord in the "basic" container case, or a
> Kubernetes-like thing in the "advanced" case. I'm personally comfortable
> with
> being less dogmatic about what goes into the container, understanding that
> there's a future on the horizon filled with Kubernetes :)
>
>
> As to the concern about the image mutability, the evergreen-client would
> only
> be effectively changing content in the mapped `/var/jenkins_home` which
> must by
> the very nature of Jenkins be mutable. I'll update JEP-301 to make that
> more
> explicit.
>
>
>
> Thanks for taking a look-see.
>
>
>
> - R. Tyler Croy
>
> --
>  Code: <https://github.com/rtyler>
>   Chatter: <https://twitter.com/agentdero>
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>

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

Re: Accelerating Jenkins development with Jenkins Essentials

[nicolas de loof]

2018-02-14 1:04 GMT+01:00 R. Tyler Croy :

> (replies inline)
>
> On Thu, 08 Feb 2018, Surya Gaddipati wrote:
>
> > Hi,
> >
> > This is exciting new development.
> >
> > Couple of comments
> >
> > 1.  Packaging supervisord with another executable is a docker anti
> pattern.
> > I assume  any serious  jenkins deployment is on a scheduler like
> > swarm/kubernetes ect where supervisord is not necessary.
>
>
> I understand the point made but I disagree with the notion that "serious"
> Jenkins deployments are using Swarm or Kubernetes. The Jenkins project
> itself
> (for example) has been running Docker in production for over four years
> now,
> without a container orchestrator of any kind. This includes
> https://ci.jenkins.io/. We use the garethr/docker Puppet module
> (https://forge.puppet.com/garethr/docker) which itself has millions of
> downloads by folks managing Docker services "the hard way." That said, we
> also
> have a Kubernetes environment where we're deploying newer applications
> (e.g.
> https://plugins.jenkins.io/) into. So I /agree/ with the point that
> Kubernetes
> is likely a good candidate for replacing some of the Jenkins lifecycle
> management work that supervisord is currently performing, which is why I
> mention Kubernetes in JEP-301 at all. However, I strongly
> disagree that the market is "there" yet, I think making a container
> orchestrator a requirement at this point would only inhibit adoption and
> learning. I am instead erring on the side of "simple and fast" from a user
> perspective, the closest we can get (IMHO) to the `java -jar jenkins.war`
> experience, the easier the adoption and experimentation will be for the
> user
> audience I want to reach.
>

I haven't found any references to supervisord in JEP pull request, neither
about kubernetes - did I miss something ?
Anyway I tend to agree with this comment about packaging supervisord with
jenkins essential within a docker image as a bad practice. I don't think
this has anything to relate to running this as plain docker or with some
orchestrator, this just makes the docker image a mutable instance, which
should be avoided. Without much details on where this discussion comes from
I can't really tell much about alternatives.


>
>
> > 2. Scripting should be done via yaml files, not environment variables(
> > init.d/groovy). All essential plugins should be made compatible with
> > configuration-as-code.
>
> I fully intend on using as much support as possible from the Configuration
> as
> Code effort which Ewelina and Nicolas are working on. I do not intend to
> undertake, as part of Jenkins Essentials, patching or updating plugins in
> order
> to support it however.
>
> My order of priority for scripting Jenkins is:
>
>  1. Configuration as Code
>  2. Groovy scripting (bleh)
>  3. Hopefully very little if any scary hacks.
>
>
> So I think we're mostly on same page here :)
>
>
Configuration-as-Code is not ready yet to support this, but for sure we
will keep an eye on this and will try to implement this use-case as well
when this becomes relevant.


>
> > 3. Pipeline while powerful is contrary to the goal of getting new users
> > started quickly. From my personal experience, very few new users have the
> > appetite to learn groovy scripting to setup their builds, they just want
> to
> > something to run `npm test`.
> > A declarative yaml file like travisci,circle ect is the *correct*
> > approach here.
>
> I agree that this is an important goal for Jenkins as a whole to consider:
> making Pipeline easier to use and be successful with. I believe those
> currently
> hacking on Pipeline, like abayer, would agree with that sentiment. What
> *is* in
> the scope of this work is making Jenkins easier to understand "out of the
> box"
> (https://github.com/jenkinsci/jep/tree/master/jep/300#obvious-path) which
> I
> believe is going to entail a number of copy-and-pasteable examples of
> common
> Jenkinsfiles, and other forms of built-in examples and documentation.
>
> Overall, thank you very much for taking the time to read JEPs and provide
> feedback. The way I am interpreting your overall feedback, and please
> correct
> me if I'm wrong, is that the direction is promising but want to encourage
> good
> fundamentals on the implementation.
>
>
>
> Anywho, thanks again :)
>
>
>
>
>
> - R. Tyler Croy
>
> --
>  Code: 
>   Chatter: 
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>
> --
> 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/2018021400

[configuration-as-code] JSON schema

[nicolas de loof]

Hi here,

Just an update on configuration-as-code effort (JEP-201)

I've started implementing schema generation for the configuration-as-code
yaml file.
it's only first iteration, so I expect some corner cases, but the main
benefits is we will be able to validate this configuration without having
to start jenkins and wait for potential failure. Another way to say, is we
can check a configuration file will result in a healthy jenkins instance.



jenkins.model.Jenkins:
{

   - type: "object",
   - properties:
   {
  - agentProtocols:
  {
 - type: "array",
 - items:
 {
- type: "string"
}
 },
  - authorizationStrategy:
  {
 - schema:
 {
- oneOf:
[
   -
   {
  - loggedInUsersCanDoAnything:
  {
 - type:

"#/definitions/hudson.security.FullControlOnceLoggedInAuthorizationStrategy"
 }
  },
   -
   {
  - legacy:
  {
 - type:
 "#/definitions/hudson.security.LegacyAuthorizationStrategy"
 }
  },
   -
   {
  - unsecured:
  {
 - type:

"#/definitions/hudson.security.AuthorizationStrategy$Unsecured"
 }
  }
   ]
}
 },

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

Re: Docker agent build script wrapper

[nicolas de loof]

Hi,

next release of docker-plugin is going to introduce "dockerNode" keyword in
pipeline, so you can create an agent from a docker image:

dockerNode(dockerHost: 'unix:///var/run/docker.sock', image:
'jenkins/slave', remoteFs: '/home/jenkins') { sh 'echo "hello there"' }


this is still under development and will first be an experimental feature
in the meantime, you can rely on docker-pipeline-plugin and docker.inside
for an equivalent.

Generally speaking, if you target multiple environments, you should not
declare a top level node, but have one per stage.

2017-11-27 11:12 GMT+01:00 Oleksandr Rudak :

> Hi,
>
> We are building scientific model running and testing environment product.
> We use Jenkins as a core building, integration and model running tool. Now
> our users are scientist and have little technological background so we look
> to fold our current Jenkinsfile into something more compact and
> transparent. We've tried few things. SimpleBuildStep, which is too basic to
> handle agent/docker stuff. Step is too complicated as it involved
> distributed execution parallelism. Also we tried 'load' to load Jenkinsfile
> generated in the working directory. All ways have pros/cons but none
> provides in full what we try to accomplish.
>
> Any ideas how to do such wrapping? I think about custom `agent` which
> would provide docker context and will imply the rest of the configuration
> and hide it from user. Possibly some workflow extension or something like
> this. Any thoughts are welcome.
>
> Below is the anticipated Jenkinsfile how it would ideally look. Attached
> is the original Jenkins with detailed steps we want to cloak from user.
>
> node {
> stage ('setup') {
> setupEnv (dockerImage:'dockerImage123')
> }
> stage ('train') {
> runNotebook (notebookPath:'notebookPath212')
> // { prepare, run, archive, legion }
> // runNotebook (notebookPath:'notebookPath213')
> }
> stage ('deploy') {
> deployModel ()
> }
> stage ('test') {
> testModel ()
> }
> }
>
>
>
> Thanks
> Alex
>
> --
> 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/5a2441d6-72ef-45f7-a415-356510c8a9cc%
> 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/CANMVJzmLW_c67%3DrO7CLk7k_L5FZeZFiw33SGQh2X36Ty-rovDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

Thanks !

2017-11-27 23:53 GMT+01:00 Jesse Glick :

> On Fri, Nov 24, 2017 at 8:17 AM, nicolas de loof
>  wrote:
> > I'm looking if stapler can
> > easily answer "does this descriptor have a global view" without making
> > assumption on the view template language
>
> Try `Descriptor.getGlobalConfigPage`.
>
> --
> 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/CANfRfr2G8BuOuprwSpnSgT8uOof_
> KaWbW7m-P0C8ETHTa61afA%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/CANMVJznxhBahay1WnKM2Oc_VmM8TzaR%2BnapFXZ-%2Bs9fmnniYZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

Yes this is a good short terms workaround.  I'm looking if stapler can
easily answer "does this descriptor have a global view" without making
assumption on the view template language, but I think your fix is ok for
now, please push it to main repository

2017-11-24 14:07 GMT+01:00 Ewelina Wilkosz :

> when I changed
>
> URL global = ConfigurationAsCode.class.getClassLoader().getResource(
> cl+"/global.jelly");
> to
>
> URL global = descriptor.getKlass().toJavaClass().getClassLoader()
> .getResource(cl+"/global.jelly");
> it started working for me...
>
> On Friday, November 24, 2017 at 1:54:10 PM UTC+1, nicolas de loof wrote:
>>
>> You're right, that was a distinct (non blocking) issue.
>>
>> this global.jelly lookup was working for me as I had mailer plugin
>> declared as a dependency and ran mvn hpi:run for testing, so this lib is in
>> core classpath
>> will need to investigate a better way to check a Descriptor has a
>> global.jelly view (I'm so pleased to dig into Stapler internals :P)
>>
>>
>>
>> 2017-11-24 13:34 GMT+01:00 Ewelina Wilkosz :
>>
>>> It looks the list is not empty, it's URL global = ConfigurationAsCode.
>>> class.getClassLoader().getResource(cl+"/global.jelly"); that returns
>>> null, is it the same issue you're talking about?
>>>
>>> On Friday, November 24, 2017 at 10:19:19 AM UTC+1, nicolas de loof wrote:
>>>>
>>>> yes indeed, for a reason I don't understand yet,
>>>> "Jenkins.getInstance().getExtensionList(Descriptor.class)" returns an
>>>> empty list :-\
>>>> investigating ...
>>>>
>>>> 2017-11-24 9:51 GMT+01:00 Ewelina Wilkosz :
>>>>
>>>>> Hi Nicolas, I have a problem with configuring mailer
>>>>> - if I use "mailer:" as root element Jenkins won't start - exact copy
>>>>> from demo folder
>>>>> - if I put mailer under "jenkins:" root element there is no error on
>>>>> startup but no configuration is applied
>>>>>
>>>>> Is there anything special about that one, that should maybe be
>>>>> mentioned in the documentation?
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, November 23, 2017 at 3:27:19 PM UTC+1, nicolas de loof
>>>>> wrote:
>>>>>>
>>>>>> I wrote this documentation
>>>>>> <https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/PLUGINS.md>
>>>>>>  for
>>>>>> plugin developers to understand the required changes so we can support
>>>>>> Descriptor as configuration-as-code targets.
>>>>>> I'll work on writing some pull-requests applying this approach to
>>>>>> some major plugins.
>>>>>>
>>>>>> 2017-11-15 16:27 GMT+01:00 nicolas de loof :
>>>>>>
>>>>>>> this is really work in progress, i.e not even tested on my own
>>>>>>> before I propose this in a PR :P
>>>>>>> was just for information that I was looking into implementing a fix
>>>>>>> for this idea
>>>>>>>
>>>>>>> 2017-11-15 16:24 GMT+01:00 Jesse Glick :
>>>>>>>
>>>>>>>> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>>>>>>>>  wrote:
>>>>>>>> > proposed improvement to Descriptor.configure  (WiP) :
>>>>>>>> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>>>>>>>>
>>>>>>>> If you are soliciting feedback, just file as a PR and mark as
>>>>>>>> `work-in-progress`. Easier to gather comments that way.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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/CANfRfr0%2Bd
>>>>>>>> %2BE1RO8PTVeUHnpvH3367zd6D%2Bwa2%2BAeSTgTd9Zc4Q%40mail.gmail.com.
>>>>>>>> For more options, visit htt

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

You're right, that was a distinct (non blocking) issue.

this global.jelly lookup was working for me as I had mailer plugin declared
as a dependency and ran mvn hpi:run for testing, so this lib is in core
classpath
will need to investigate a better way to check a Descriptor has a
global.jelly view (I'm so pleased to dig into Stapler internals :P)



2017-11-24 13:34 GMT+01:00 Ewelina Wilkosz :

> It looks the list is not empty, it's URL global = ConfigurationAsCode.
> class.getClassLoader().getResource(cl+"/global.jelly"); that returns
> null, is it the same issue you're talking about?
>
> On Friday, November 24, 2017 at 10:19:19 AM UTC+1, nicolas de loof wrote:
>>
>> yes indeed, for a reason I don't understand yet,
>> "Jenkins.getInstance().getExtensionList(Descriptor.class)" returns an
>> empty list :-\
>> investigating ...
>>
>> 2017-11-24 9:51 GMT+01:00 Ewelina Wilkosz :
>>
>>> Hi Nicolas, I have a problem with configuring mailer
>>> - if I use "mailer:" as root element Jenkins won't start - exact copy
>>> from demo folder
>>> - if I put mailer under "jenkins:" root element there is no error on
>>> startup but no configuration is applied
>>>
>>> Is there anything special about that one, that should maybe be mentioned
>>> in the documentation?
>>>
>>>
>>>
>>> On Thursday, November 23, 2017 at 3:27:19 PM UTC+1, nicolas de loof
>>> wrote:
>>>>
>>>> I wrote this documentation
>>>> <https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/PLUGINS.md>
>>>>  for
>>>> plugin developers to understand the required changes so we can support
>>>> Descriptor as configuration-as-code targets.
>>>> I'll work on writing some pull-requests applying this approach to some
>>>> major plugins.
>>>>
>>>> 2017-11-15 16:27 GMT+01:00 nicolas de loof :
>>>>
>>>>> this is really work in progress, i.e not even tested on my own before
>>>>> I propose this in a PR :P
>>>>> was just for information that I was looking into implementing a fix
>>>>> for this idea
>>>>>
>>>>> 2017-11-15 16:24 GMT+01:00 Jesse Glick :
>>>>>
>>>>>> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>>>>>>  wrote:
>>>>>> > proposed improvement to Descriptor.configure  (WiP) :
>>>>>> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>>>>>>
>>>>>> If you are soliciting feedback, just file as a PR and mark as
>>>>>> `work-in-progress`. Easier to gather comments that way.
>>>>>>
>>>>>> --
>>>>>> 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/CANfRfr0%2Bd
>>>>>> %2BE1RO8PTVeUHnpvH3367zd6D%2Bwa2%2BAeSTgTd9Zc4Q%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-de...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-dev/99138212-72cf-47e8-b002-8e00974e1c44%40goo
>>> glegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/99138212-72cf-47e8-b002-8e00974e1c44%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/eb597cea-7a8e-43ec-a311-42bc44a80c7b%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/eb597cea-7a8e-43ec-a311-42bc44a80c7b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJznGxsNNam1bmxC7WRUXavabpZt0P6PBXOaNvwS3JKWkLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

yes indeed, for a reason I don't understand yet,
"Jenkins.getInstance().getExtensionList(Descriptor.class)" returns an empty
list :-\
investigating ...

2017-11-24 9:51 GMT+01:00 Ewelina Wilkosz :

> Hi Nicolas, I have a problem with configuring mailer
> - if I use "mailer:" as root element Jenkins won't start - exact copy from
> demo folder
> - if I put mailer under "jenkins:" root element there is no error on
> startup but no configuration is applied
>
> Is there anything special about that one, that should maybe be mentioned
> in the documentation?
>
>
>
> On Thursday, November 23, 2017 at 3:27:19 PM UTC+1, nicolas de loof wrote:
>>
>> I wrote this documentation
>> <https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/PLUGINS.md>
>>  for
>> plugin developers to understand the required changes so we can support
>> Descriptor as configuration-as-code targets.
>> I'll work on writing some pull-requests applying this approach to some
>> major plugins.
>>
>> 2017-11-15 16:27 GMT+01:00 nicolas de loof :
>>
>>> this is really work in progress, i.e not even tested on my own before I
>>> propose this in a PR :P
>>> was just for information that I was looking into implementing a fix for
>>> this idea
>>>
>>> 2017-11-15 16:24 GMT+01:00 Jesse Glick :
>>>
>>>> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>>>>  wrote:
>>>> > proposed improvement to Descriptor.configure  (WiP) :
>>>> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>>>>
>>>> If you are soliciting feedback, just file as a PR and mark as
>>>> `work-in-progress`. Easier to gather comments that way.
>>>>
>>>> --
>>>> 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/ms
>>>> gid/jenkinsci-dev/CANfRfr0%2Bd%2BE1RO8PTVeUHnpvH3367zd6D%2Bw
>>>> a2%2BAeSTgTd9Zc4Q%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/99138212-72cf-47e8-b002-8e00974e1c44%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/99138212-72cf-47e8-b002-8e00974e1c44%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJzk0dLcx0cskzejC-GNEQJc%2BmGZZbhFiZSKKet3rwQaNzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

I wrote this documentation
<https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/PLUGINS.md>
for
plugin developers to understand the required changes so we can support
Descriptor as configuration-as-code targets.
I'll work on writing some pull-requests applying this approach to some
major plugins.

2017-11-15 16:27 GMT+01:00 nicolas de loof :

> this is really work in progress, i.e not even tested on my own before I
> propose this in a PR :P
> was just for information that I was looking into implementing a fix for
> this idea
>
> 2017-11-15 16:24 GMT+01:00 Jesse Glick :
>
>> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>>  wrote:
>> > proposed improvement to Descriptor.configure  (WiP) :
>> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>>
>> If you are soliciting feedback, just file as a PR and mark as
>> `work-in-progress`. Easier to gather comments that way.
>>
>> --
>> 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/ms
>> gid/jenkinsci-dev/CANfRfr0%2Bd%2BE1RO8PTVeUHnpvH3367zd6D%2Bw
>> a2%2BAeSTgTd9Zc4Q%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/CANMVJzm_9LxAKdc3wbXYQ-U2KRPS5OKM-r%2BFZA5UHuf-0Y3NFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

this is really work in progress, i.e not even tested on my own before I
propose this in a PR :P
was just for information that I was looking into implementing a fix for
this idea

2017-11-15 16:24 GMT+01:00 Jesse Glick :

> On Wed, Nov 15, 2017 at 9:51 AM, nicolas de loof
>  wrote:
> > proposed improvement to Descriptor.configure  (WiP) :
> > https://github.com/ndeloof/jenkins/tree/JENKINS-48018
>
> If you are soliciting feedback, just file as a PR and mark as
> `work-in-progress`. Easier to gather comments that way.
>
> --
> 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/CANfRfr0%2Bd%2BE1RO8PTVeUHnpvH3367zd6D%
> 2Bwa2%2BAeSTgTd9Zc4Q%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/CANMVJzn2X3r45HQmUyHYKOFF%3DCrgJvv2TGi_2OOU7Rw0Xz3UMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

proposed improvement to Descriptor.configure  (WiP) :
https://github.com/ndeloof/jenkins/tree/JENKINS-48018

*tl;dr: *
provide default implementation to Descriptor#configure using databinding.
reset descriptor to default values based on properties types default *or*
convention to declare a public {{property}}_default constant. Also updated
jelly taglibs to use this same constant in form inputs as default value
(until explicitly set)

>>> this configuration mechanism isn't atomic, and
>>> there's some possible race condition for related attributes to have
>>> inconsistent values seen from another thread while the configuration is
>>> being changed.
>>
>> This isn't a new problem, right?
>
> It _would_ be a new problem if you refactored an existing
> configuration form to use the recommended idioms and thereby
> introduced the race condition.

No, this race condition already exists while one submit configuration form,
whenever we use @databound or not, other threads _already_ can see
descriptor in a weird intermediate state. Hopefully one does not update
global configuration every millisecond.

2017-11-15 15:44 GMT+01:00 Jesse Glick :

> On Tue, Nov 14, 2017 at 10:19 PM, Kohsuke Kawaguchi 
> wrote:
> > I suppose we could create a variant of req.bindJSON(this,json) that does
> set
> > null on proeprties that are not specified in JSON.
>
> Yes, that would be a helpful convenience API, and it would make sense
> to call it in a newly introduced default implementation for
> `Descriptor.configure`. For compatibility reasons we could probably
> not change the implementation of `GlobalConfiguration.configure`,
> unfortunately.
>
> >> this configuration mechanism isn't atomic, and
> >> there's some possible race condition for related attributes to have
> >> inconsistent values seen from another thread while the configuration is
> >> being changed.
> >
> > This isn't a new problem, right?
>
> It _would_ be a new problem if you refactored an existing
> configuration form to use the recommended idioms and thereby
> introduced the race condition.
>
> > When this matters some use of
> > 'synchronized' statement is in order anyway.
>
> Would not help. You can synchronize `configure(StaplerRequest,
> JSONObject)` so that the nulling out of all properties followed by the
> setting of most properties is atomic. But that will not protect
> individual `@DataBoundSetter` calls from the proposed C-a-C plugin. We
> would need to introduce a scripting-friendly API for configuring an
> arbitrary object (create new `Describable` or modify existing
> `Descriptor` or `ReconfigurableDescribable`), but without any tie to
> Stapler or web forms, along the lines of
>
> http://javadoc.jenkins.io/workflow-step-api/org/
> jenkinsci/plugins/workflow/steps/StepDescriptor.html#
> newInstance-java.util.Map-
>
> This could live in `structs` though we would then have a problem with
> any affected settings defined in `jenkins-core`.
>
> The more straightforward workaround for such cases is the use of an
> explicit object representing a zero choice, as I mentioned previously.
> This does have an effect on the UI, at least using the currently
> available controls (which would only support a dropdown or a radio
> button list, not a checkbox).
>
> --
> 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/CANfRfr0fLxzZ_4JtTsedFY_-22wdLCJGBuR1e%3DOcKCdD9Zrz%
> 3DA%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/CANMVJzn0g2StRCR%2B5Q5Vb_ikORphSmM8Xzu%2B-%3DCf6L-5oXxohA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

This is a comparable issue indeed, even this applies to  updateByXml. not
configure(json)
https://github.com/jenkinsci/jenkins/pull/2736 is a promising approach, but
is discovering attributes via reflection, while configuration-as-code is
looking at ui-bound parameters. In many case they are the same but not
always the case. Anyway this gives me some inspiration to propose a fix.

2017-11-13 21:45 GMT+01:00 Daniel Beck :

>
> > On 13. Nov 2017, at 20:26, Jesse Glick  wrote:
> >
> >>
> >> if I UNCHECK the optional property, no "authentication" value
> >> is posted to JSON form, and I don't get SMTPAuthentication reset to
> null in
> >> my descriptor.
> >
> > Unfortunately your `configure` override must start by setting any
> > optional struct fields to null:
>
> Is this just JENKINS-21017 again, or something else?
>
> --
> 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/230C492B-23E2-4816-BB0A-5647E749AB15%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/CANMVJznZpTa%2B7_uC8NvoTd5fBW-33rMWpsaKkG8%2BupVVB5P-%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

Right, so hopefully we already have docs on best practices for plugin
developers ;)

An issue remain. Let's consider I refactor Mailer plugin to adopt this
approach (see
https://github.com/ndeloof/mailer-plugin/commit/ffc57e0ff1cb1b74dc1d6fdcb2329a5b9141daaa),
with a new nested optionalProperty describable SMTPAuthentication
<https://github.com/ndeloof/mailer-plugin/blob/master/src/main/java/hudson/tasks/SMTPAuthentication.java>
{ username, password } to replace nullable attributes in Mailer$Descriptor

I'll rewrite configure method as :

public boolean configure(StaplerRequest req, JSONObject json) throws
FormException {

req.bindJSON(this, json);
save();
return true;
}


(by the way, shouldn't this be the default implementation ?)

But with this, if I UNCHECK the optional property, no
"authentication" value is posted to JSON form, and I don't get
SMTPAuthentication reset to null in my descriptor.
AFAICT Describable mechanism  documented here
<https://jenkins.io/doc/developer/plugin-development/pipeline-integration> only
supports immutable components.

Does this mean Descriptors would need to include an extra "reset" method to
set all attributes to null / default value ?
This also make me think this configuration mechanism isn't atomic, and
there's some possible race condition for related attributes to have
inconsistent values seen from another thread while the configuration is
being changed.

As a resume, and considering recommended and well adopted approach to
retrieve a Descriptor is to use
Jenkins.getInstance.getDescriptor(describable), not referring to some final
static constant, I wonder we could get the Descriptor.configure mechanism
to rely on @DataBoundConstructors just like Describable do.
This means we will need to (atomically) swap Descriptor instance in
ExtensionList. Maybe this has too much impact (extensionLists Memoizer
would need to be reset) ? Or maybe there's a better way to support
re-configuration with @DataBound ?



2017-11-10 0:13 GMT+01:00 Jesse Glick :

> On Thu, Nov 9, 2017 at 9:45 AM, nicolas de loof
>  wrote:
> > As a sample for this
> > discussion let's consider Mailer plugin build step
>
> And the comment
>
> > this code is brain dead
>
> :-)
>
> > Until you have some clever hack to suggest, it looks to me we will need
> to
> > provide guidance for plugin developers for "best practice to implement
> > Descriptor" so it can be used by configuration-as-code.
>
> A lot of this is actually identical to the constraints needed to make
> code compatible with *Pipeline Syntax*, and more broadly with the
> `DescribableModel` API. See:
>
> https://jenkins.io/doc/developer/plugin-development/pipeline-integration/#
> constructor-vs-setters
>
> > I sounds to me we don't have any way to provide a generic mechanism
> without
> > changes to Descriptors in core/plugins - yes I known, this means hundreds
> > pull-requests
>
> Start filing them…
>
> The main difficulty is not in writing correct code, which is in fact
> usually easier than the old way, it is in maintaining deserialization
> compatibility. So you need to use `readResolve` and occasionally even
> XStream tricks to load old, awkward property layouts into a logical
> revised structure.
>
> > To reuse Mailer$Descriptor sample, this would require useSMTPAuth to be
> an
> > actual nested data structure, not just a boolean flag to configure some
> > optional attributes. This means that it would have to define a nested
> java
> > class to own smtpAuthUserName + smtpAuthPasswordSecret attributes.
>
> Yes. `f:optionalProperty` and a nested `Describable`. See for example
> `HeteroList` in `ui-samples`.
>
> --
> 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/CANfRfr3Vq3AVbvMFQDiB2xApKiqT%
> 3Dswcsr%3D606V5OuKVrkKZmA%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/CANMVJz%3DDrRF%3DXM8rp0A-zyt4D6wTXTBU2eQ_YFZ%3DHjQyHxzGpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[configuration-as-code] Descriptors configuration

[nicolas de loof]

This message is a follow up for discussion on
https://github.com/jenkinsci/jep/pull/31#discussion_r149598856

configuration-as-code 
prototype include generic mechanism to configure arbitrary jenkins
component relying on @DataBound* ui-binding methods.
but configuration also include Descriptors, and many of them do rely on
programmatic data-binding parsing JSONObject. As a sample for this
discussion let's consider Mailer plugin build step


This one has attributes, which don't match the UI databound attributes. For
sample (for legacy reasons) Java attribute smtpHost is expose on UI as
smtpServer
(here

)

This one uses an optional block in configuration, and as a result it relie
son a pseudo boolean attribute useSMTPAuth

(== descriptor.smtpAuthUserName!=null

) and unset related attributes to null if not selected.

So

   - We can rely on getXXX methods to discover attributes - we can
   guarantee they're defined
   - BUT we can't guess psuedo-attributes like useSMTPAuth
   
,
   neither can we guess the nested JSON document this one involves :
{ "useSMTPAuth" : { "smtpAuthUserName" : ..., "smtpAuthPasswordSecret"
   : ... } }


As a resume :

   - We can't invoke @DataBoundSetters for those attributes. Some exist for
   Mailer bu tin many cases they don't (they're not required by a Descriptor)
   - We can't event directly set attributes using Field.setAccessible hack,
   as name isn't guaranteed to match (see smtpHost != smtpServer)
   - We can't invoke configure(StaplerRequest, JSONObject) as we can't
   guess the required nested JSON document structure

Until you have some clever hack to suggest, it looks to me we will need to
provide guidance for plugin developers for "*best practice to implement
Descriptor*" so it can be used by configuration-as-code.
I sounds to me we don't have any way to provide a generic mechanism without
changes to Descriptors in core/plugins - yes I known, this means hundreds
pull-requests :'(


Can we just ask them to rely on @DataBound ?
Please remind a Descriptor is a *mutable* object, i.e if someone un-select
some option, the target component won't get attribute reset to null.

To reuse Mailer$Descriptor sample, this would require useSMTPAuth to be an
actual nested data structure, not just a boolean flag to configure some
optional attributes. This means that it would have to define a nested java
class to own smtpAuthUserName + smtpAuthPasswordSecret attributes.

Any thoughts ?

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

Draft JEP: Configuration as Code

[nicolas de loof]

Hi,

Some of you who joined Contributor Summit at Jenkins World'17 already know
about the resurrecting effort to provide configuration-as-code for Jenkins
management (JENKINS-31094)

Both Praqma and CloudBees have been investigating on this topic last
months, and have wrote prototypes to cover this need. As we learned about
each other effort we decided to join forces, and make this public as a JEP
proposal.

Our joined prototype is here :
https://github.com/jenkinsci/configuration-as-code-plugin
We also wrote a document to explain our goals and design decisions. We used JEP
template

so
we can now propose this for JEP acceptance (I guess this is the right place
to do so)

We'll be happy to hear from you about this.

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

Re: Request to become maintainer on docker-plugin

[nicolas de loof]

2017-09-06 16:15 GMT+02:00 Jesse Glick :

> On Tue, Sep 5, 2017 at 8:28 PM, Oleg Nenashev 
> wrote:
> > […] while it's still compatible with Docker Plugin use-cases
>
> One of my reservations about both the `docker-plugin` and the
> `yet-another-docker-plugin` (BTW both incorrectly include `-plugin` in
> the `artifactId`) is that they try to solve too many things, and are
> cluttered with various builders you do not really need. A plugin
> should either focus on letting a job request an image for specific
> build steps, as `docker-workflow` and
> `docker-custom-build-environment` do; or provide a solid `Cloud`
> implementation for the case that the whole agent JVM runs inside a
> globally configured container (IMO the main reason to use
> `docker-plugin`); or something in between, as `docker-slaves`
> creatively attempts.
>

I totally agree, and I'm not sure how to fix this. I wonder docker-plugin
could be refactored so the cloud agents part is extracted in some
"docker-cloud" plugin, and those builders into another one (unfortunately
we already have docker-build-step-plugin. Another one would add to the
confusion). Docker plugin would then just act as some agregator plugin,
maybe only offer some global configuration for Registry / DockerHost


>
> --
> 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/CANfRfr04rUG_93UkFQv3vwqMVxvnWfE8RFUaQ-C%
> 2B3jRy%2BvAWKw%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/CANMVJzn3muoX9PFCP%3D93MUY1YbCUdwofCLnv0uEYv%3D1viCTs2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer on docker-plugin

[nicolas de loof]

I still plan to work on docker-slaves plugin, but if possible I indeed
would like to introduce some bits from it into docker-plugin. Typically
ability to create an agent by combining containers. But too early to tell
you more until I've spent some more hours in docker-plugin codebase :P

2017-09-06 10:59 GMT+02:00 Richard Bywater :

> @Nicolas - Interestingly out of the Docker plugin implementations I've
> tried so far, https://github.com/jenkinsci/docker-slaves-plugin has come
> closest to working the way I'd expect. Do you see that you'd roll some of
> that work into the Docker plugin or do it going down a completely different
> path?
>
> Richard.
>
> On Wed, 6 Sep 2017 at 20:10 Baptiste Mathus  wrote:
>
>> As Nigel gave his +1, I went ahead and made you committer Nicolas.
>> Remember to file the necessary PR on https://github.com/jenkins-
>> infra/repository-permissions-updater if/when you want to release.
>>
>> I tend to agree with Oleg, probably some cleanup already occurred in YAD,
>> but also agreed it's a very borderline plugin in terms of governance:
>> hosted outside <https://github.com/KostyaSha/yet-another-docker-plugin>
>> the org, but still publishing releases
>> <http://repo.jenkins-ci.org/public/com/github/kostyasha/yet-another-docker/yet-another-docker-parent/>
>> ...
>>
>> 2017-09-06 9:03 GMT+02:00 Nigel Magnay :
>>
>>> Please - go for it. I don't have the bandwidth these days to support it
>>> in anything like a timely manner.
>>>
>>> On Tue, 5 Sep 2017 at 18:20, nicolas de loof 
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> docker-plugins as 20 pull requests pending for review and no new
>>>> commits since Nov 16th.
>>>> I volunteer to adopt this plugin. Especially I'd like to have
>>>> docker-plugin support docker swarm mode, so it can distribute builds on a
>>>> cluster out of the box.
>>>>
>>>> Github-ID: ndeloof
>>>>
>>>> Jenkins-ID: ndeloof
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Nicolas
>>>>
>>> --
>>> 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/CAPYP83S68h76obfuTvDAihHTRZ88p
>>> 6uOmdmzHeT1K23XY4Oxtg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83S68h76obfuTvDAihHTRZ88p6uOmdmzHeT1K23XY4Oxtg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/CANWgJS7bR0Cmy8u%3DfAURRwTxW%
>> 3DZt1J95VDvO3uZHeTtAka5-wQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7bR0Cmy8u%3DfAURRwTxW%3DZt1J95VDvO3uZHeTtAka5-wQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CANMVJzm9k66C%3DFBC51VyZddNaXXva-kQWOi6CBn56P%2B5OkdS_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Request to become maintainer on docker-plugin

[nicolas de loof]

Hi folks,

docker-plugins as 20 pull requests pending for review and no new commits
since Nov 16th.
I volunteer to adopt this plugin. Especially I'd like to have docker-plugin
support docker swarm mode, so it can distribute builds on a cluster out of
the box.

Github-ID: ndeloof

Jenkins-ID: ndeloof


Cheers,

Nicolas

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

Re: Status of docker-slaves-plugin

[nicolas de loof]

cool. Can you at least share your use-case so we understand the impacts ?

2017-07-10 12:31 GMT+02:00 Richard Bywater :

> Thanks Nicolas - quite understand that things take time away from having
> much time to work on things.
>
> Just as a FYI I've been making a few tweaks/fixes to meet my use-cases and
> I'm trying to get sign-off from the powers that be to be able to share them
> back. Assuming the sign-off comes I'll be creating a few PRs against the
> project which hopefully the wider community will find useful.
>
> Cheers
> Richard.
>
> On Mon, 10 Jul 2017 at 22:22 nicolas de loof 
> wrote:
>
>> Hi Richard,
>>
>> We indeed aren't very active on this plugin, due to various other
>> business activity
>> There's various aspect of this plugin that we want to improve, most
>> significant one being to fabric8io/docker-client as a client library so we
>> don't have to use external docker CLI to interact with Docker host.
>>
>> As you can see, this is mostly a plumbing effort, that might result in
>> some 2.x. From user I know who use this plugin, they're just happy with the
>> provided feature
>>
>> 2017-07-04 9:00 GMT+02:00 Oleg Nenashev :
>>
>>> Added Nicolas and Yoann to Cc. The plugin is not marked for adoption, so
>>> probably they have some plans about it.
>>>
>>> вторник, 4 июля 2017 г., 7:24:07 UTC+2 пользователь Richard Bywater
>>> написал:
>>>>
>>>> Hi
>>>>
>>>> Just wondering what the status of the Docker Slaves Plugin (
>>>> https://github.com/jenkinsci/docker-slaves-plugin ) is?
>>>>
>>>> Last commit was 7 months ago and there's a couple of PRs open on it
>>>> that have been open a while too.
>>>>
>>>> Reason I ask is that I'm looking to start using it in anger on our
>>>> team's Jenkins instances but want to understand the "support" situation
>>>> first :)
>>>>
>>>> Richard
>>>>
>>>>
>> --
>> 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/CANMVJzkUasWxkDt0CV-hDCwcXkQJ34QDDCd8QZF_%3D_
>> r30CogCA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkUasWxkDt0CV-hDCwcXkQJ34QDDCd8QZF_%3D_r30CogCA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CAMui947TihOeJCrhJevhN26tELHJG
> i4LVyOOnijTCGw0m7uHvA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMui947TihOeJCrhJevhN26tELHJGi4LVyOOnijTCGw0m7uHvA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJznZN5V1VktD%2BzR9AwG9qcQSqoYeLAbU5%2BRpC-GCcRSADA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of docker-slaves-plugin

[nicolas de loof]

Hi Richard,

We indeed aren't very active on this plugin, due to various other business
activity
There's various aspect of this plugin that we want to improve, most
significant one being to fabric8io/docker-client as a client library so we
don't have to use external docker CLI to interact with Docker host.

As you can see, this is mostly a plumbing effort, that might result in some
2.x. From user I know who use this plugin, they're just happy with the
provided feature

2017-07-04 9:00 GMT+02:00 Oleg Nenashev :

> Added Nicolas and Yoann to Cc. The plugin is not marked for adoption, so
> probably they have some plans about it.
>
> вторник, 4 июля 2017 г., 7:24:07 UTC+2 пользователь Richard Bywater
> написал:
>>
>> Hi
>>
>> Just wondering what the status of the Docker Slaves Plugin (
>> https://github.com/jenkinsci/docker-slaves-plugin ) is?
>>
>> Last commit was 7 months ago and there's a couple of PRs open on it that
>> have been open a while too.
>>
>> Reason I ask is that I'm looking to start using it in anger on our team's
>> Jenkins instances but want to understand the "support" situation first :)
>>
>> Richard
>>
>>

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

few broken artifacts in jenkins' maven repo

[nicolas de loof]

Doing some work related to plugin management, I noticed some minor issues
with repo.jenkins-ci.org

https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/job-dsl/1.33/job-dsl-1.33.hpi
is actually a pom.xml

https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/bitbucket-build-status-notifier/1.3.2/bitbucket-build-status-notifier-1.3.2.hpi
is actually a text file "target/bitbucket-build-status-notifier.hpi"

build-configurator-1.0.6.0.hpi is listed on
https://repo.jenkins-ci.org/public/com/amcbridge/build-configurator/1.0.6.0/
but not available (404)

-- 
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/CANMVJzmZie%2BMw7Kn9xd%2B3PRYTCtyTCo%3DTUvWKMhhukTMDANsqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

lost permission to write on jenkinsci/docker-ssh-slave

[nicolas de loof]

Hi,

I'm declared as maintainer on jenkinsci/docker-ssh-slave docker image but
don't have write permission on the github repo
https://github.com/jenkinsci/docker-ssh-slave

not sure where to request this. IIUC
https://github.com/jenkins-infra/repository-permissions-updater/tree/master/permissions
is for Artifactory permissions, isn't it ?

-- 
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/CANMVJz%3DHVBpoqVHgnj9thPc-zy%3DZycLuYFUmhpFR4eorh9xtYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: maintainer requests

[nicolas de loof]

oh, sorry for that, I'm used with typos on my name :P

2016-11-01 20:57 GMT+01:00 Daniel Beck :

>
> > On 01.11.2016, at 18:57, nicolas de loof 
> wrote:
> >
> > I don't maintain NodeJS plugin, so feel free to take over
>
> To clarify, Nikolas Falco who has also requested access. I didn't get your
> first name wrong ;-)
>
> --
> 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/F42479A9-00E3-4D7A-A8DC-0327EFACE255%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/CANMVJz%3DztUx3vfs91o9qOwZGXrc3d9K6QRY0P3bPDQD7xtVNTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: maintainer requests

[nicolas de loof]

I don't maintain NodeJS plugin, so feel free to take over

2016-11-01 18:39 GMT+01:00 Daniel Beck :

>
> > On 01.11.2016, at 12:58, Greg Langston  wrote:
> >
> > Thanks guys. Anything else you need from me to finalize?
>
> I'd like to know which of the plugins you'd like to maintain since it
> looks like ECR would be co-maintained with Ivan, and NodeJS with Nikolas.
>
> --
> 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/0D73BC6B-3D95-41C3-A816-D331A68EA272%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/CANMVJzmKDxYiy7Sf6WQbJX7W3XQg6EN4SXAnj8nRseUpDzbTmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

I indeed think we will have to support the evil maven job type for one more
decade, so need to make it flexible enough so migrating jenkins codebase to
a newer JDK is not blocked y this beast. As maven do support toolchain, I
just would like maven job do fully rely on it without any extra
configuration so end user don't have to worry about this terrible runtime
dependency.

2016-10-29 10:24 GMT+02:00 Arnaud Héritier :

> Are you proposing to write a real/good toolchain integration for Jenkins ?
> That will allow to generate / configure the config file based on what
> Jenkins deploys ? Ok with docker it is simpler to create an image with
> several JDKs and the configuration file hardcoded (in that case the
> challenge is to choose the docker plugin to use ..)
>
>
> Le samedi 29 octobre 2016, nicolas de loof  a
> écrit :
>
>> ... or rely on tool chain, that has been designed to cover this exact
>> issue.
>> Didn't we had this debate few days ago ?
>>
>> Le 29 oct. 2016 9:48 AM, "Arnaud Héritier"  a
>> écrit :
>>
>>> If you don't use the maven evil job type
>>>
>>> Le samedi 29 octobre 2016, nicolas de loof  a
>>> écrit :
>>>
>>>> Jenkins can require Java 8, but needs to support building arbitrary
>>>> Java project, even jdk 1.0 ;)
>>>>
>>>> Le 29 oct. 2016 1:40 AM, "Martina"  a écrit :
>>>>
>>>>> btw. game-of-life that we all dearly love for demos only runs with
>>>>> jdk7, not jdk 8, at least the master branch does.
>>>>> https://github.com/CloudBees-community/game-of-life
>>>>> Not sure how/where to report it, so I'm guessing that the right
>>>>> powers-to-be see this one.
>>>>>
>>>>> - Martina
>>>>>
>>>>> --
>>>>> 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/c233f009-00a
>>>>> 4-4795-bcee-61502007dd64%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/c233f009-00a4-4795-bcee-61502007dd64%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> 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/ms
>>>> gid/jenkinsci-dev/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b
>>>> 3uES4%3D7t%2BJA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b3uES4%3D7t%2BJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>> --
>>> -
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>>>
>>> --
>>> 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/ms
>>> gid/jenkinsci-dev/CAFNCU-_LvYDHV8o3LKsBBsz58veXMVyGDWyHmOM78
>>> 7f18ckbpw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_LvYDHV8o3LKsBBsz58veXMVyGDWyHmOM787f18ckbpw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

... or rely on tool chain, that has been designed to cover this exact issue.
Didn't we had this debate few days ago ?

Le 29 oct. 2016 9:48 AM, "Arnaud Héritier"  a écrit :

> If you don't use the maven evil job type
>
> Le samedi 29 octobre 2016, nicolas de loof  a
> écrit :
>
>> Jenkins can require Java 8, but needs to support building arbitrary Java
>> project, even jdk 1.0 ;)
>>
>> Le 29 oct. 2016 1:40 AM, "Martina"  a écrit :
>>
>>> btw. game-of-life that we all dearly love for demos only runs with jdk7,
>>> not jdk 8, at least the master branch does.
>>> https://github.com/CloudBees-community/game-of-life
>>> Not sure how/where to report it, so I'm guessing that the right
>>> powers-to-be see this one.
>>>
>>> - Martina
>>>
>>> --
>>> 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/ms
>>> gid/jenkinsci-dev/c233f009-00a4-4795-bcee-61502007dd64%40goo
>>> glegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/c233f009-00a4-4795-bcee-61502007dd64%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/ms
>> gid/jenkinsci-dev/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b
>> 3uES4%3D7t%2BJA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b3uES4%3D7t%2BJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
> --
> 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/CAFNCU-_LvYDHV8o3LKsBBsz58veXMVyGDWyHm
> OM787f18ckbpw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_LvYDHV8o3LKsBBsz58veXMVyGDWyHmOM787f18ckbpw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJzmRZ%2BT9B%2BVz46K-v8OgkwtC%2B7AUjnCoNR1DHg9ufrZFbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

Jenkins can require Java 8, but needs to support building arbitrary Java
project, even jdk 1.0 ;)

Le 29 oct. 2016 1:40 AM, "Martina"  a écrit :

> btw. game-of-life that we all dearly love for demos only runs with jdk7,
> not jdk 8, at least the master branch does. https://github.com/CloudBees-
> community/game-of-life
> Not sure how/where to report it, so I'm guessing that the right
> powers-to-be see this one.
>
> - Martina
>
> --
> 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/c233f009-00a4-4795-bcee-61502007dd64%
> 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/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b3uES4%3D7t%2BJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

Have just read Java 9 is postponed to 2017/07/27, give us some extra time
to look into this

2016-10-19 7:47 GMT+02:00 nicolas de loof :

> @Oleg I totally agree we need to investigate java 9 support  - for your
> information, jenkins doesn't boot on java9+jigsaw, see
> https://github.com/x-stream/xstream/issues/74
>
>
>
> 2016-10-18 23:42 GMT+02:00 Oleg Nenashev :
>
>> Weak -1 regarding JDK8, but the opinion is not that strong.
>> I'm pretty sure that now it will be a pretty big problem for low-end
>> platfroms like Embedded Systems with hand-made OpenJDK builds.
>>
>> We should rather consider investing into Java 9 Early Access IMHO. People
>> will likely start submitting issues soon, and we may have serious issues
>> with upgrade of our old lib forks
>>
>> BR, Oleg
>>
>> суббота, 15 октября 2016 г., 19:57:49 UTC+2 пользователь Kanstantsin
>> Shautsou написал:
>>>
>>> ROR
>>>
>>> 2016-10-15 21:21 GMT+04:00 Arnaud Héritier :
>>>
>>>> FYI PR#66 I would like to apply Olivier's comment before applying it
>>>> and PR#66 daniel's comment.
>>>>
>>>>
>>>> Le samedi 15 octobre 2016, Arnaud Héritier  a
>>>> écrit :
>>>>
>>>>> I was supposed to work on it yesterday but I had a problem at home and
>>>>> I had to stop to work early. There are 2 PRs I would like to finalize
>>>>> before the release. I hope to do it tomorrow evening or at the later on
>>>>> Monday. I don't know if Olivier had some others todo ?
>>>>>
>>>>> Le samedi 15 octobre 2016, Kanstantsin Shautsou <
>>>>> kanstantsin@gmail.com> a écrit :
>>>>>
>>>>>> I have no stacktrace and test case as we replaced guice to released
>>>>>> version in our custom build. Will do of course when get again, but PR in
>>>>>> core is blocked only by maven-plugin release.
>>>>>>
>>>>>> --
>>>>>> 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/d71732a5-c11
>>>>>> 8-446d-a1d1-01438ce3e3bd%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/d71732a5-c118-446d-a1d1-01438ce3e3bd%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -
>>>>> Arnaud Héritier
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>> Twitter/Skype : aheritier
>>>>>
>>>>>
>>>>
>>>> --
>>>> -
>>>> Arnaud Héritier
>>>> http://aheritier.net
>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>> Twitter/Skype : aheritier
>>>>
>>>> --
>>>> 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/to
>>>> pic/jenkinsci-dev/fo5nKLhZK5U/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> jenkinsci-de...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/jenkinsci-dev/CAFNCU-8XUYxeQ-fardYEBoEy1zPOxWn%2B2HYhPbH
>>>> 4XMYqqxjQ3w%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8XUYxeQ-fardYEBoEy1zPOxWn%2B2HYhPbH4XMYqqxjQ3w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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/ms
>> gid/jenkinsci-dev/10beaf2b-6b64-4b7b-8c35-9ef100014bda%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/10beaf2b-6b64-4b7b-8c35-9ef100014bda%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/CANMVJzmSdi%2BPZuHF7Jdu5ZQRHSNNGzSLChkzPosvVjzpo45-zQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

@Oleg I totally agree we need to investigate java 9 support  - for your
information, jenkins doesn't boot on java9+jigsaw, see
https://github.com/x-stream/xstream/issues/74



2016-10-18 23:42 GMT+02:00 Oleg Nenashev :

> Weak -1 regarding JDK8, but the opinion is not that strong.
> I'm pretty sure that now it will be a pretty big problem for low-end
> platfroms like Embedded Systems with hand-made OpenJDK builds.
>
> We should rather consider investing into Java 9 Early Access IMHO. People
> will likely start submitting issues soon, and we may have serious issues
> with upgrade of our old lib forks
>
> BR, Oleg
>
> суббота, 15 октября 2016 г., 19:57:49 UTC+2 пользователь Kanstantsin
> Shautsou написал:
>>
>> ROR
>>
>> 2016-10-15 21:21 GMT+04:00 Arnaud Héritier :
>>
>>> FYI PR#66 I would like to apply Olivier's comment before applying it and
>>> PR#66 daniel's comment.
>>>
>>>
>>> Le samedi 15 octobre 2016, Arnaud Héritier  a écrit :
>>>
 I was supposed to work on it yesterday but I had a problem at home and
 I had to stop to work early. There are 2 PRs I would like to finalize
 before the release. I hope to do it tomorrow evening or at the later on
 Monday. I don't know if Olivier had some others todo ?

 Le samedi 15 octobre 2016, Kanstantsin Shautsou <
 kanstantsin@gmail.com> a écrit :

> I have no stacktrace and test case as we replaced guice to released
> version in our custom build. Will do of course when get again, but PR in
> core is blocked only by maven-plugin release.
>
> --
> 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/d71732a5-c11
> 8-446d-a1d1-01438ce3e3bd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


 --
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier


>>>
>>> --
>>> -
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>>>
>>> --
>>> 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/to
>>> pic/jenkinsci-dev/fo5nKLhZK5U/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-dev/CAFNCU-8XUYxeQ-fardYEBoEy1zPOxWn%2B2HYhPbH
>>> 4XMYqqxjQ3w%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/10beaf2b-6b64-4b7b-8c35-9ef100014bda%
> 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/CANMVJz%3DuLYo4tgfG42QeHS4foYZSyobb5NgwVSj_2guuSJ2zzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

is there a jira issue to track this ?
I've been running jenkins on Java 8 without issue so far, so wonder about
this runtime issue.

2016-10-14 13:20 GMT+02:00 Kanstantsin Shautsou :

> Jenkins still has guice-beta that randomly fails under java8.
>
> --
> 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/cffed57e-5e26-4c06-9318-8682a6ed66f6%
> 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/CANMVJz%3D6STCjQBzDZ%3DiCAhGgs0FwT%3D3xU7bPkap_Z%2BoS%2Bh-GLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

Yes indeed,
"OpenJDK 8 is included with RHEL 6.6 (and higher) and RHEL 7.1 (and
higher), and it is fully supported."
https://access.redhat.com/solutions/795263
java-package <https://packages.debian.org/search?keywords=java-package> is
available on jessie contrib
<https://packages.debian.org/jessie/java-package>, but java 8 is only
available on wheezy in backports
<https://packages.debian.org/wheezy-backports/java-package> repo
Ubuntu : OpenJDK 8 is still not
<https://bugs.launchpad.net/trusty-backports/+bug/1368094> available in an
official backport for 14.04. It is, however, available in 14.10 and
forwards.
OpenSuse : can't tell,
http://software.opensuse.org/package/java-1_8_0-openjdk is down for
maintenance
Gentoo : not a distro I know well, but AFAIC there's no such thing as a
LTS, so just use oracle-jdk-bin
<https://packages.gentoo.org/packages/dev-java/oracle-jdk-bin> package
FreeBSD : not sure how those handle packages vs system releases.
http://www.freshports.org/java/openjdk8 doesn't give info on system version
it applies to
OpenBSD : ?

+1 for using Java 8 for windows installer package

2016-10-14 10:11 GMT+02:00 Daniel Beck :

>
> > On 14.10.2016, at 09:10, nicolas de loof 
> wrote:
> >
> > About system that don't have Java 8 in official repo (RHEL5, Debian
> Wheezy, Ubuntu 14.04 LTS).
>
> Are you saying that RHEL 6 + 7, Debian Jessie, and Ubuntu 16.04 all _do_
> have JRE 8 in their repos?
>
> What about the other distros that have Jenkins packages? openSUSE, Gentoo,
> and the BSDs?
>
> Any problems we anticipate for bundling JRE 8 with the Windows installer?
> (FWIW this could be done early, no need to wait for the runtime
> requirement…)
>
> --
> 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/2482C1BC-223B-4653-A9B4-38CBB0D8D7B3%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/CANMVJzk2n6uGbUk0OkV%2Bn9DTE-zHk6JAt_NbjPBoiqfXekjMFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

[nicolas de loof]

My +1 for Java 8 (as I have been advocating for this for 2.0 already)

About system that don't have Java 8 in official repo (RHEL5, Debian Wheezy,
Ubuntu 14.04 LTS). Oracle do provide official JDK builds as DEB/RPM, so I
can't see this as a blocker. For sure there's IT department, one need to
convince to install a runtime that isn't part of official system
repository... but that's just organisational issue we can't fix.

About maven job type, I wonder we could add better support for toolchain so
jenkins can aytomagically select/install adequate JDK on slave, create
toolchain.xml, and maybe even inject maven-toolchains-plugin in the
lifecycle (is this possible ?). Maybe too much black magic ? Any
improvement here would help getting a smooth transition.

2016-10-13 23:22 GMT+02:00 Daniel Beck :

>
> > On 13.10.2016, at 22:22, Baptiste Mathus  wrote:
> >
> >> On the wiki page of the plugin ?
> >
> >
> > Yes, I think this is probably the most sensible place.
>
> I agree. Can always be moved elsewhere if needed, but as it's plugin
> specific (and not even part of the default configuration of Jenkins
> anymore…), plugin wiki page makes sense.
>
> --
> 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/84457EDE-0578-4373-9600-07B59352F96F%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/CANMVJzm0HkEK1MHM9t%2BVSZTtfXMMcVLWXLzYyzH_DDp%3DmXDehA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting CMS or G1 as the default GC algorithm for Jenkins?

[nicolas de loof]

+1

2016-10-06 23:29 GMT+02:00 Samuel Van Oort :

> Hi guys,
> I'd like to propose that we explicitly set the Java args for the Jenkins
> packages to use either Concurrent Mark Sweep or G1 as the default GC
> algorithm.
>
> The reason for this is that Jenkins is generally used as a long-running
> server process, and large stop-the-world GC pauses can pose a problem for
> stability and user experience.   The default Java GC algorithm (ParallelGC)
> is tuned to optimize throughput at the expense of potentially multi-second
> major GC pauses with large heaps, which is obviously not a good fit for
> this case. This is why Oracle is moving to G1 as the default as of Java 9.
>
> I would suggest either CMS or G1 make good defaults for normal Jenkins
> users, because they greatly reduce average and maximum GC pause times.
>
> Thoughts?
>
> Regards,
> Sam Van Oort
>
> --
> 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/c009a299-1b23-4cb8-97ef-c6718fc279e1%
> 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/CANMVJzmBaccZgfd93-_pEomH6CVF93w5J5AZjpRuVoKqG0RpzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Manage our forks as ... git forks

[nicolas de loof]

My initial proposal was to rename existing as -legacy, which would result
in something comparable.

Le 3 oct. 2016 9:07 PM, "Kanstantsin Shautsou" 
a écrit :

> Backup, delete, fork, push back?
>
> On Oct 3, 2016, at 22:05, Baptiste Mathus  wrote:
>
> So, anyway, now we know. It's not possible to attach a fork afterwards
> <https://twitter.com/GitHubHelp/status/783018024056029184>.
>
> 2016-10-03 14:52 GMT+02:00 nicolas de loof :
>
>> I'm not sure we can get such a repo easily configured as a fork from
>> xstream
>> Also, this wouldn't help much to maintain our commits as we would then
>> have two independent commit trees in the same repo
>>
>> Anyway, if this is considered a better approach, I'm fine with it
>>
>> 2016-10-03 14:45 GMT+02:00 Kanstantsin Shautsou > gmail.com>:
>>
>>> I mean utilise existing repo instead of creating new. Everything the
>>> same that would be done in new repo, but in old.
>>>
>>> On Oct 3, 2016, at 15:40, nicolas de loof 
>>> wrote:
>>>
>>> Not sure I understand your suggestion, how would this help get commits
>>> back and forth jenkins and xstream plugin ?
>>>
>>>
>>>
>>> 2016-10-03 14:30 GMT+02:00 Kanstantsin Shautsou >> gmail.com>:
>>>
>>>> But you can create scratch branch and import anything into?
>>>>
>>>>
>>>> On Oct 3, 2016, at 15:22, nicolas de loof 
>>>> wrote:
>>>>
>>>> Our custom fork don't share any commit with the x-stream one as we only
>>>> imported xstream releases to "incoming" branch. So we don't share history
>>>> and there's nothing we could link to.
>>>>
>>>> I've tried to use git grafts to re-attach xstream recent commits to
>>>> Jenkins repo, but didn't got it to work, and also grafts can't be pushed to
>>>> github (this is a local hack)
>>>>
>>>>
>>>> 2016-10-03 14:15 GMT+02:00 Kanstantsin Shautsou >>> gmail.com>:
>>>>
>>>>> Maybe try firstly try only with this repo?
>>>>>
>>>>> On Oct 3, 2016, at 15:09, Baptiste Mathus  wrote:
>>>>>
>>>>> Yup. Just asked through the GitHub support UI.
>>>>>
>>>>> Then if we agree, I guess we'll just be left with creating the list of
>>>>> repos to "reconcile" and issue a support request to batch update them via
>>>>> support.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> 2016-10-03 13:58 GMT+02:00 Kanstantsin Shautsou >>>> gmail.com>:
>>>>>
>>>>>> Just write to support, they react really fast and solve issues.
>>>>>>
>>>>>> On Oct 3, 2016, at 14:57, Baptiste Mathus  wrote:
>>>>>>
>>>>>> Maybe GitHub could just set up the link on existing repos to
>>>>>> [conceptually] forked ones? I've asked them on Twitter to see if they 
>>>>>> have
>>>>>> an answer. Might be possible, since the contrary is and we regularly ask
>>>>>> them to "break" fork links.
>>>>>>
>>>>>> 2016-10-03 13:03 GMT+02:00 Kanstantsin Shautsou >>>>> l.com>:
>>>>>>
>>>>>>> +1 Url in top of page should be enough imho.
>>>>>>> Maybe name repository `xstream-jenkins` as project do `-jenkins`
>>>>>>> releases?
>>>>>>>
>>>>>>> On Monday, October 3, 2016 at 11:16:17 AM UTC+3, nicolas de loof
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I've created https://github.com/jenkinsci/xstream-fork, branch
>>>>>>>> "jenkins" is based on upstream tag 1.4.7 + diff from our fork, so code 
>>>>>>>> is
>>>>>>>> equivalent to https://github.com/jenkinsci/xstream
>>>>>>>>
>>>>>>>> Are you OK I documented on jenkinsci/xstream this repo is
>>>>>>>> deprecated and redirect users to jenkinsci/xstream-fork if they want to
>>>>>>>> propose PRs ?
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-09-30 23:35 GMT+02:00 Mark Waite :
>>>>>>>>

Re: Manage our forks as ... git forks

[nicolas de loof]

I'm not sure we can get such a repo easily configured as a fork from xstream
Also, this wouldn't help much to maintain our commits as we would then have
two independent commit trees in the same repo

Anyway, if this is considered a better approach, I'm fine with it

2016-10-03 14:45 GMT+02:00 Kanstantsin Shautsou :

> I mean utilise existing repo instead of creating new. Everything the same
> that would be done in new repo, but in old.
>
> On Oct 3, 2016, at 15:40, nicolas de loof 
> wrote:
>
> Not sure I understand your suggestion, how would this help get commits
> back and forth jenkins and xstream plugin ?
>
>
>
> 2016-10-03 14:30 GMT+02:00 Kanstantsin Shautsou  >:
>
>> But you can create scratch branch and import anything into?
>>
>>
>> On Oct 3, 2016, at 15:22, nicolas de loof 
>> wrote:
>>
>> Our custom fork don't share any commit with the x-stream one as we only
>> imported xstream releases to "incoming" branch. So we don't share history
>> and there's nothing we could link to.
>>
>> I've tried to use git grafts to re-attach xstream recent commits to
>> Jenkins repo, but didn't got it to work, and also grafts can't be pushed to
>> github (this is a local hack)
>>
>>
>> 2016-10-03 14:15 GMT+02:00 Kanstantsin Shautsou <
>> kanstantsin@gmail.com>:
>>
>>> Maybe try firstly try only with this repo?
>>>
>>> On Oct 3, 2016, at 15:09, Baptiste Mathus  wrote:
>>>
>>> Yup. Just asked through the GitHub support UI.
>>>
>>> Then if we agree, I guess we'll just be left with creating the list of
>>> repos to "reconcile" and issue a support request to batch update them via
>>> support.
>>>
>>> WDYT?
>>>
>>> Cheers
>>>
>>>
>>> 2016-10-03 13:58 GMT+02:00 Kanstantsin Shautsou <
>>> kanstantsin@gmail.com>:
>>>
>>>> Just write to support, they react really fast and solve issues.
>>>>
>>>> On Oct 3, 2016, at 14:57, Baptiste Mathus  wrote:
>>>>
>>>> Maybe GitHub could just set up the link on existing repos to
>>>> [conceptually] forked ones? I've asked them on Twitter to see if they have
>>>> an answer. Might be possible, since the contrary is and we regularly ask
>>>> them to "break" fork links.
>>>>
>>>> 2016-10-03 13:03 GMT+02:00 Kanstantsin Shautsou >>> l.com>:
>>>>
>>>>> +1 Url in top of page should be enough imho.
>>>>> Maybe name repository `xstream-jenkins` as project do `-jenkins`
>>>>> releases?
>>>>>
>>>>> On Monday, October 3, 2016 at 11:16:17 AM UTC+3, nicolas de loof wrote:
>>>>>>
>>>>>> I've created https://github.com/jenkinsci/xstream-fork, branch
>>>>>> "jenkins" is based on upstream tag 1.4.7 + diff from our fork, so code is
>>>>>> equivalent to https://github.com/jenkinsci/xstream
>>>>>>
>>>>>> Are you OK I documented on jenkinsci/xstream this repo is deprecated
>>>>>> and redirect users to jenkinsci/xstream-fork if they want to propose PRs 
>>>>>> ?
>>>>>>
>>>>>>
>>>>>> 2016-09-30 23:35 GMT+02:00 Mark Waite :
>>>>>>
>>>>>>> Wouldn't it be better to leave the existing repository with its
>>>>>>> current name to prevent breaking anyone who depends on that location, 
>>>>>>> then
>>>>>>> create the forked repository under an entirely new name (like 
>>>>>>> xstream-fork)?
>>>>>>>
>>>>>>> Other than that minor item, I think it is an interesting idea to
>>>>>>> clearly show projects which are forks of an upstream project.
>>>>>>>
>>>>>>> Mark Waite
>>>>>>>
>>>>>>> On Fri, Sep 30, 2016 at 2:32 PM nicolas de loof <
>>>>>>> nicolas...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Jenkins uses some custom builds of external libraries, typically
>>>>>>>> XStream.
>>>>>>>> Today such projects are hosted on github, which would make easier
>>>>>>>> to keep in sync and/or propose fixes to upstream 

Re: Manage our forks as ... git forks

[nicolas de loof]

Not sure I understand your suggestion, how would this help get commits back
and forth jenkins and xstream plugin ?



2016-10-03 14:30 GMT+02:00 Kanstantsin Shautsou :

> But you can create scratch branch and import anything into?
>
>
> On Oct 3, 2016, at 15:22, nicolas de loof 
> wrote:
>
> Our custom fork don't share any commit with the x-stream one as we only
> imported xstream releases to "incoming" branch. So we don't share history
> and there's nothing we could link to.
>
> I've tried to use git grafts to re-attach xstream recent commits to
> Jenkins repo, but didn't got it to work, and also grafts can't be pushed to
> github (this is a local hack)
>
>
> 2016-10-03 14:15 GMT+02:00 Kanstantsin Shautsou  >:
>
>> Maybe try firstly try only with this repo?
>>
>> On Oct 3, 2016, at 15:09, Baptiste Mathus  wrote:
>>
>> Yup. Just asked through the GitHub support UI.
>>
>> Then if we agree, I guess we'll just be left with creating the list of
>> repos to "reconcile" and issue a support request to batch update them via
>> support.
>>
>> WDYT?
>>
>> Cheers
>>
>>
>> 2016-10-03 13:58 GMT+02:00 Kanstantsin Shautsou <
>> kanstantsin@gmail.com>:
>>
>>> Just write to support, they react really fast and solve issues.
>>>
>>> On Oct 3, 2016, at 14:57, Baptiste Mathus  wrote:
>>>
>>> Maybe GitHub could just set up the link on existing repos to
>>> [conceptually] forked ones? I've asked them on Twitter to see if they have
>>> an answer. Might be possible, since the contrary is and we regularly ask
>>> them to "break" fork links.
>>>
>>> 2016-10-03 13:03 GMT+02:00 Kanstantsin Shautsou >> l.com>:
>>>
>>>> +1 Url in top of page should be enough imho.
>>>> Maybe name repository `xstream-jenkins` as project do `-jenkins`
>>>> releases?
>>>>
>>>> On Monday, October 3, 2016 at 11:16:17 AM UTC+3, nicolas de loof wrote:
>>>>>
>>>>> I've created https://github.com/jenkinsci/xstream-fork, branch
>>>>> "jenkins" is based on upstream tag 1.4.7 + diff from our fork, so code is
>>>>> equivalent to https://github.com/jenkinsci/xstream
>>>>>
>>>>> Are you OK I documented on jenkinsci/xstream this repo is deprecated
>>>>> and redirect users to jenkinsci/xstream-fork if they want to propose PRs ?
>>>>>
>>>>>
>>>>> 2016-09-30 23:35 GMT+02:00 Mark Waite :
>>>>>
>>>>>> Wouldn't it be better to leave the existing repository with its
>>>>>> current name to prevent breaking anyone who depends on that location, 
>>>>>> then
>>>>>> create the forked repository under an entirely new name (like 
>>>>>> xstream-fork)?
>>>>>>
>>>>>> Other than that minor item, I think it is an interesting idea to
>>>>>> clearly show projects which are forks of an upstream project.
>>>>>>
>>>>>> Mark Waite
>>>>>>
>>>>>> On Fri, Sep 30, 2016 at 2:32 PM nicolas de loof 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Jenkins uses some custom builds of external libraries, typically
>>>>>>> XStream.
>>>>>>> Today such projects are hosted on github, which would make easier to
>>>>>>> keep in sync and/or propose fixes to upstream project. But we can't
>>>>>>> reconcile existing repository with project's github.
>>>>>>>
>>>>>>> Typical sample :
>>>>>>> https://github.com/jenkinsci/xstream/ vs https://github.com/
>>>>>>> x-stream/xstream
>>>>>>>
>>>>>>> I suggest we rename such a repo on jenkinsci organization as
>>>>>>> "-legacy", then fork the upstream project, and apply a diff to ensure we
>>>>>>> get our own changes back (or maybe try to cherry-pick patches, which 
>>>>>>> would
>>>>>>> be nicer but more complex).
>>>>>>>
>>>>>>> We could then ensure PR made to jenkinsci are also proposed to
>>>>>>> upstream project and we only include fixes that are strictly related to
>>>>>>> jen

Re: Manage our forks as ... git forks

[nicolas de loof]

Our custom fork don't share any commit with the x-stream one as we only
imported xstream releases to "incoming" branch. So we don't share history
and there's nothing we could link to.

I've tried to use git grafts to re-attach xstream recent commits to Jenkins
repo, but didn't got it to work, and also grafts can't be pushed to github
(this is a local hack)


2016-10-03 14:15 GMT+02:00 Kanstantsin Shautsou :

> Maybe try firstly try only with this repo?
>
> On Oct 3, 2016, at 15:09, Baptiste Mathus  wrote:
>
> Yup. Just asked through the GitHub support UI.
>
> Then if we agree, I guess we'll just be left with creating the list of
> repos to "reconcile" and issue a support request to batch update them via
> support.
>
> WDYT?
>
> Cheers
>
>
> 2016-10-03 13:58 GMT+02:00 Kanstantsin Shautsou  >:
>
>> Just write to support, they react really fast and solve issues.
>>
>> On Oct 3, 2016, at 14:57, Baptiste Mathus  wrote:
>>
>> Maybe GitHub could just set up the link on existing repos to
>> [conceptually] forked ones? I've asked them on Twitter to see if they have
>> an answer. Might be possible, since the contrary is and we regularly ask
>> them to "break" fork links.
>>
>> 2016-10-03 13:03 GMT+02:00 Kanstantsin Shautsou > l.com>:
>>
>>> +1 Url in top of page should be enough imho.
>>> Maybe name repository `xstream-jenkins` as project do `-jenkins`
>>> releases?
>>>
>>> On Monday, October 3, 2016 at 11:16:17 AM UTC+3, nicolas de loof wrote:
>>>>
>>>> I've created https://github.com/jenkinsci/xstream-fork, branch
>>>> "jenkins" is based on upstream tag 1.4.7 + diff from our fork, so code is
>>>> equivalent to https://github.com/jenkinsci/xstream
>>>>
>>>> Are you OK I documented on jenkinsci/xstream this repo is deprecated
>>>> and redirect users to jenkinsci/xstream-fork if they want to propose PRs ?
>>>>
>>>>
>>>> 2016-09-30 23:35 GMT+02:00 Mark Waite :
>>>>
>>>>> Wouldn't it be better to leave the existing repository with its
>>>>> current name to prevent breaking anyone who depends on that location, then
>>>>> create the forked repository under an entirely new name (like 
>>>>> xstream-fork)?
>>>>>
>>>>> Other than that minor item, I think it is an interesting idea to
>>>>> clearly show projects which are forks of an upstream project.
>>>>>
>>>>> Mark Waite
>>>>>
>>>>> On Fri, Sep 30, 2016 at 2:32 PM nicolas de loof 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Jenkins uses some custom builds of external libraries, typically
>>>>>> XStream.
>>>>>> Today such projects are hosted on github, which would make easier to
>>>>>> keep in sync and/or propose fixes to upstream project. But we can't
>>>>>> reconcile existing repository with project's github.
>>>>>>
>>>>>> Typical sample :
>>>>>> https://github.com/jenkinsci/xstream/ vs https://github.com/
>>>>>> x-stream/xstream
>>>>>>
>>>>>> I suggest we rename such a repo on jenkinsci organization as
>>>>>> "-legacy", then fork the upstream project, and apply a diff to ensure we
>>>>>> get our own changes back (or maybe try to cherry-pick patches, which 
>>>>>> would
>>>>>> be nicer but more complex).
>>>>>>
>>>>>> We could then ensure PR made to jenkinsci are also proposed to
>>>>>> upstream project and we only include fixes that are strictly related to
>>>>>> jenkins usage, or at least changes we approved might be included in a
>>>>>> future upstream project release
>>>>>>
>>>>>> wdyt ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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.co
>>>>>> m/d/msgid/jenkinsci-d

Re: Manage our forks as ... git forks

[nicolas de loof]

I've created https://github.com/jenkinsci/xstream-fork, branch "jenkins" is
based on upstream tag 1.4.7 + diff from our fork, so code is equivalent to
https://github.com/jenkinsci/xstream

Are you OK I documented on jenkinsci/xstream this repo is deprecated and
redirect users to jenkinsci/xstream-fork if they want to propose PRs ?


2016-09-30 23:35 GMT+02:00 Mark Waite :

> Wouldn't it be better to leave the existing repository with its current
> name to prevent breaking anyone who depends on that location, then create
> the forked repository under an entirely new name (like xstream-fork)?
>
> Other than that minor item, I think it is an interesting idea to clearly
> show projects which are forks of an upstream project.
>
> Mark Waite
>
> On Fri, Sep 30, 2016 at 2:32 PM nicolas de loof 
> wrote:
>
>> Hi,
>>
>> Jenkins uses some custom builds of external libraries, typically XStream.
>> Today such projects are hosted on github, which would make easier to keep
>> in sync and/or propose fixes to upstream project. But we can't reconcile
>> existing repository with project's github.
>>
>> Typical sample :
>> https://github.com/jenkinsci/xstream/ vs https://github.com/x-
>> stream/xstream
>>
>> I suggest we rename such a repo on jenkinsci organization as "-legacy",
>> then fork the upstream project, and apply a diff to ensure we get our own
>> changes back (or maybe try to cherry-pick patches, which would be nicer but
>> more complex).
>>
>> We could then ensure PR made to jenkinsci are also proposed to upstream
>> project and we only include fixes that are strictly related to jenkins
>> usage, or at least changes we approved might be included in a future
>> upstream project release
>>
>> wdyt ?
>>
>>
>> --
>> 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/CANMVJznvDaPk0t%2BMTbgDmiHb34eGZUT%
>> 3DLZJVCjd2VOcEcgDsyw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznvDaPk0t%2BMTbgDmiHb34eGZUT%3DLZJVCjd2VOcEcgDsyw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> 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/CAO49JtGPpRL%3Dh0kHeQ2Lh4isi6eNrboSZYhzRMdx
> 9PRm%2Bghz6A%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGPpRL%3Dh0kHeQ2Lh4isi6eNrboSZYhzRMdx9PRm%2Bghz6A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CANMVJz%3DA2V2YVjOi5EY7xBnD%2BKJBRBWFaSD_dczv0b8K5oyc_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Manage our forks as ... git forks

[nicolas de loof]

Hi,

Jenkins uses some custom builds of external libraries, typically XStream.
Today such projects are hosted on github, which would make easier to keep
in sync and/or propose fixes to upstream project. But we can't reconcile
existing repository with project's github.

Typical sample :
https://github.com/jenkinsci/xstream/ vs https://github.com/x-stream/xstream

I suggest we rename such a repo on jenkinsci organization as "-legacy",
then fork the upstream project, and apply a diff to ensure we get our own
changes back (or maybe try to cherry-pick patches, which would be nicer but
more complex).

We could then ensure PR made to jenkinsci are also proposed to upstream
project and we only include fixes that are strictly related to jenkins
usage, or at least changes we approved might be included in a future
upstream project release

wdyt ?

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

Re: Docker workflow runs with user not fully configured

[nicolas de loof]

This indeed is required so the actual files on workspace don't get
corrupted by user IDs/premissions that only exist in your container.
You should configure your container to relax permission and let arbitrary
user run your build tools


2016-09-02 12:05 GMT+02:00 Oliver Gondža :

> I am tying to get jenkinsci/packaging to work from Pipeline using
> docker-workflow-plugin:
>
> ```
> builder = docker.build 'jenkins-packaging-builder:0.1'
> builder.inside {
> sh "make rpm ..."
> }
> ```
>
> All seems well except that rpmbuild comaplins at a couple of places: no
> $HOME is defined, the uid/gid for generated files does not exist in the
> system.
>
> The problem is the pluign instructs docker to "use" user with uid/gid
> matching the outer user (so filesystem can be shared) but the user account
> does not exist inside. It seems that docker "creates" the user to come
> extend but it is not fully configured causing tools to fail in weird ways.
>
> I guess I can switch to use the container as root somehow or update the
> image to create some user for this purpose but this seems like an inherent
> struggle with the approach. What is the best practice here?
>
> In case it is relevant I am using docker 1.10.3 and docker-workflow-plugin
> 1.6.
>
> Thanks
> --
> 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/ms
> gid/jenkinsci-dev/2f6e4595-80e0-18ba-2e2a-6a1053aa0d87%40gmail.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/CANMVJzkLSUCU4sfCMS38o%2BUsbx4q%3DVx-eYcTRaF5dRT7nbTmDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backporting for 2.7.1 has started

[nicolas de loof]

2016-06-09 18:43 GMT+02:00 Oleg Nenashev :

> @Nicolas
>
>> Any chance for
>> https://github.com/jenkinsci/jenkins/commit/310c952602f7241cb74454b7e7fb2be0bf3d2980
>> to be backported ? https://issues.jenkins-ci.org/browse/JENKINS-34923
>
>
> This an improvement, which changes the API.
> In order to make it backportable, you should ensure that there is no
> external API users and add @Restricted then.
>

not sure I get it, what do you mean by "no external API users" ? API was
changed extended so it can be used from one-shot-executor plugin. Not sure
how @Restricted works, but seems this would block this usage, right ?
Then will need to wait for a future LTS.


> If it works, I think backporiting into .2 may be justified.
>
> 2016-06-09 18:07 GMT+02:00 nicolas de loof :
>
>> Any chance for
>> https://github.com/jenkinsci/jenkins/commit/310c952602f7241cb74454b7e7fb2be0bf3d2980
>> to be backported ?
>> https://issues.jenkins-ci.org/browse/JENKINS-34923
>>
>> not even released yet, so I would be fine if you answer "no way", but
>> this is a minor code change (new event on RunListener) and will let me
>> release one-shot-executor which could help a lot in docker and other
>> container-related plugins.
>>
>> 2016-06-09 14:57 GMT+02:00 Oleg Nenashev :
>>
>>> Hi,
>>>
>>> Uh, 2.8 got 3 bad community ratings without any explanation. Nothing in
>>> the bugtracker as well :(
>>>
>>> I think we should backport all 2.8 fixes, because they will be compliant
>>> with 2-week soaking interval by the release. The following 2.8 fixes are
>>> really important IMHO:
>>>
>>>- JENKINS-35206 <https://issues.jenkins-ci.org/browse/JENKINS-35206>
>>>- must have, regression fix
>>>- JENKINS-34881 <https://issues.jenkins-ci.org/browse/JENKINS-34881>-
>>>almost must have, because it causes really bad UX for instances with
>>>preconfigured security (containers, Boot Hook scripts)
>>>- PR-2386 <https://github.com/jenkinsci/jenkins/pull/2386> - Bump of
>>>the Windows slave installer, fix slave installation flow for modern 
>>> Windows
>>>OS versions
>>>- JENKINS-35178 <https://issues.jenkins-ci.org/browse/JENKINS-35178>
>>>- UX issue on config pages in Safari
>>>
>>> I would also consider PR 2379
>>> <https://github.com/jenkinsci/jenkins/pull/2379>, because it slightly
>>> improves Jenkins WebUI performance. JENKINS-31915 seems to be important as
>>> well, but there is not so much votes for this fix.
>>>
>>>
>>> Regarding non-released changes, maybe we want to consider the following:
>>>
>>>- Remoting 2.60:
>>>
>>> https://github.com/jenkinsci/remoting/blob/master/CHANGELOG.md#260-coming-soon
>>>(ETA - next Jenkins weekly)
>>>- https://github.com/jenkinsci/jenkins/pull/2398 (usage stats over
>>>HTTPs only)
>>>
>>>
>>> BR, Oleg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> четверг, 9 июня 2016 г., 12:05:57 UTC+2 пользователь Robert Sandell
>>> написал:
>>>>
>>>> Exciting! :D
>>>>
>>>> On Wed, Jun 8, 2016 at 8:49 PM, Oliver Gondža  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Next LTS release line was selected. The backporting has started and
>>>>> the RC will be published 2016-06-22.
>>>>>
>>>>> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
>>>>> Fixed:
>>>>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.7.1-fixed
>>>>> --
>>>>> 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-de...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/4af38d30-773d-fa5d-d237-fe256d6fc58f%40gmail.com
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Robert Sandell
>>>> *Software Engineer*
>>>>

Re: Backporting for 2.7.1 has started

[nicolas de loof]

Any chance for
https://github.com/jenkinsci/jenkins/commit/310c952602f7241cb74454b7e7fb2be0bf3d2980
to be backported ?
https://issues.jenkins-ci.org/browse/JENKINS-34923

not even released yet, so I would be fine if you answer "no way", but this
is a minor code change (new event on RunListener) and will let me release
one-shot-executor which could help a lot in docker and other
container-related plugins.

2016-06-09 14:57 GMT+02:00 Oleg Nenashev :

> Hi,
>
> Uh, 2.8 got 3 bad community ratings without any explanation. Nothing in
> the bugtracker as well :(
>
> I think we should backport all 2.8 fixes, because they will be compliant
> with 2-week soaking interval by the release. The following 2.8 fixes are
> really important IMHO:
>
>- JENKINS-35206  -
>must have, regression fix
>- JENKINS-34881 -
>almost must have, because it causes really bad UX for instances with
>preconfigured security (containers, Boot Hook scripts)
>- PR-2386  - Bump of
>the Windows slave installer, fix slave installation flow for modern Windows
>OS versions
>- JENKINS-35178  -
>UX issue on config pages in Safari
>
> I would also consider PR 2379
> , because it slightly
> improves Jenkins WebUI performance. JENKINS-31915 seems to be important as
> well, but there is not so much votes for this fix.
>
>
> Regarding non-released changes, maybe we want to consider the following:
>
>- Remoting 2.60:
>
> https://github.com/jenkinsci/remoting/blob/master/CHANGELOG.md#260-coming-soon
>(ETA - next Jenkins weekly)
>- https://github.com/jenkinsci/jenkins/pull/2398 (usage stats over
>HTTPs only)
>
>
> BR, Oleg
>
>
>
>
>
>
>
>
>
>
> четверг, 9 июня 2016 г., 12:05:57 UTC+2 пользователь Robert Sandell
> написал:
>>
>> Exciting! :D
>>
>> On Wed, Jun 8, 2016 at 8:49 PM, Oliver Gondža  wrote:
>>
>>> Hi,
>>>
>>> Next LTS release line was selected. The backporting has started and the
>>> RC will be published 2016-06-22.
>>>
>>> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
>>> Fixed:
>>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.7.1-fixed
>>> --
>>> 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-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/4af38d30-773d-fa5d-d237-fe256d6fc58f%40gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Robert Sandell
>> *Software Engineer*
>> *CloudBees Inc.*
>>
> --
> 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/3050071d-3e43-4cfa-993a-ff63d4380aa6%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/CANMVJznF8P4UU7JE9xT_HzCdj2pi7cx%2B%3D%2Bqr8M_UXSSe82YT9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trouble building Blue Ocean

[nicolas de loof]

I have the docker image running locally and can't see any broken link.
Could you please give more details ? screenshot ?

2016-05-30 8:52 GMT+02:00 Michael Neale :

> Hrm, what are some links that you see broken? I have seen it run on /
> before - I wonder if the image has the wrong context root set somehow.
>
>
> On Sunday, May 29, 2016 at 12:10:40 AM UTC+10, Ross Boucher wrote:
>>
>> Thanks. I got the docker image running, but it looks like there's a
>> problem with jenkins believing it will be running at /jenkins/, but out of
>> the box it seems to be configured to actually run at the web root /. (The
>> initial page load works, but most links are broken).
>>
>> On Saturday, May 28, 2016 at 9:54:19 AM UTC-4, Baptiste Mathus wrote:
>>>
>>> Hi Ross,
>>>
>>> That's great! Depending on what you were planning to do (have a look, or
>>> start hacking on it?), if (at first) it's only playing with it, then you
>>> might want to use the dedicated docker image:
>>>
>>> $ docker run -p 8080:8080  jenkinsci/blueocean
>>>
>>> About your local error, I think you're just trying to build a maven
>>> module of the whole repo, but that plugin actually depends on some others.
>>>
>>> So, first get back to the root of the repo, and run
>>>
>>> $ mvn clean install
>>>
>>> That will build and install all the plugins inside what's the local
>>> maven cache (or somewhat improperly /repository/, but really it's better to
>>> see it as a cache. Anyway).
>>>
>>> Then run hpi:run like you did.
>>>
>>> Cheers!
>>>
>>> 2016-05-28 15:45 GMT+02:00 Ross Boucher :
>>>
 Hey all, I'm excited about the new Blue Ocean project. Tried to get it
 running just now and I'm running into some trouble. After running `mvn
 clean install`, on the next step, I'm getting this:

 https://gist.github.com/boucher/1a9beb22ac3cbadf858a82f4db05c0f2

 Any suggestions?

 -Ross

 --
 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/e2fbb62c-ad36-4f67-bdfd-898186a83316%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/e753e554-b411-4036-b1b2-000c8bb4ce91%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/CANMVJz%3D3i0NtdzPSPrm6VO-0X9%2BXOyvPHuU1FURjWxFtN6-5AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Blue Ocean] New UX project for jenkins

[nicolas de loof]

yes indeed, see
https://github.com/jenkinsci/blueocean-plugin/pull/1/files/d14ffb3f68d4b21f76bd1b800fb74c5806e97db8#r64960271

2016-05-27 18:04 GMT+02:00 Tom Fennelly :

> I think Nicolas already has something cooked up and ready to go for this.
> We'll let you know when it's ready.
>
> On Friday, May 27, 2016 at 1:51:38 PM UTC+1, Stanislas Chollet wrote:
>>
>> Thanks James.
>>
>> I just created an issue on JIRA ->
>> https://issues.jenkins-ci.org/browse/JENKINS-35181
>>
>> Regards,
>>
>> On Friday, May 27, 2016 at 2:29:12 PM UTC+2, James Dumay wrote:
>>>
>>> We have a docker image that gets published daily to a private Docker
>>> repository but we need to move it to a public repository. Could you file an
>>> issue on JIRA with the Blue Ocean component?
>>> On Fri, May 27, 2016 at 10:27 PM, Stanislas Chollet <
>>> stanisla...@gmail.com> wrote:
>>>
 Hello Michael,

 Good job ! This new fresh UI is really a good improvement for the
 jenkins project !

 I wondering if there is a Docker image of Blue Ocean to try it directly
 on a existing installation ?

 Have a good day,

 On Friday, May 27, 2016 at 12:44:06 AM UTC+2, Michael Neale wrote:
>
> I just opened https://issues.jenkins-ci.org/browse/HOSTING-98 for the
> so-called "blueocean" plugin.
>
> You may have heard this announced via the blog post
> https://jenkins.io//blog/2016/05/26/introducing-blue-ocean/. If not,
> I'll give you a few minutes
>
> to have a read...
>
> Just kidding, who has time for that, let me explain. No, there is too
> much, let me sum up:
>
> https://www.youtube.com/watch?v=GZYhDMCOyww
>
> (above is from the movie princess bride, more seriously, if you
> haven't seen this movie you really should, kind of urgently)
>
> Blue Ocean aims to be a plugin (well, a few moving parts delivered as
> plugins) that provides an extensible "next gen" user experience. Jenkins
> GUI has been around for 10 years now, and can be hard to extend and
> modernise (many of us have tried).
>
> Its initial focus is on "pipeline centric" and freestyle views for the
> busy developer, and is very much a work in progress.
>
> The interesting bits for us developers:
>
> Blue Ocean is based on ES6
> ,
> Server Sent Events
> 
> (realtime notifications), React.js
> 
> for component model and gulp/npm  build
> chain, but wired in via the already in use jenkins-js modules
>  (this means there isn’t a
> need to be familiar with the whole js toolchain unless you want to be, and
> mvn install takes care of things normally).
>
> Both client side (stuff in browser) and server side - are just Jenkins
> plugins. The server side uses the usual Jenkins web middleware (yes,
> stapler) and extensions/extension points.
>
> A fair bit of head scratching was done to come up with an
> “” concept for blue ocean client side, however it was 
> worth
> it as it means that plugins for the new UX can be delivered as normal
> Jenkins plugins but with js componentry. Jenkins serves up these plugins 
> to
> the web browser so extension points in Blue Ocean pages can be fulfilled 
> by
> any plugin offering those extensions (GUI extension points have names).
> This includes things like adding a new “route” for a new page to host a
> feature, or could be augmenting an existing page or component. A sample
> plugin and demo of it is here:
> https://github.com/cloudbees/blueocean-sample-pipeline-result-ext-plugin.
>
>
> Extensions can be isolated in failure this way - so a bad bit of
> javascript doesn’t brick a whole page.
>
> Blue Ocean when installed currently provides the new UX on the /blue
> top level route in Jenkins, so the classic GUI lives alongside it. The new
> GUI (markup, js) that is delivered via a fresh set of markup and JS
> bundles, so it doesn’t conflict with any existing GUI.
>
> The UX model in blue ocean is more of a shift to what used to be
> called “client server” but is now a “single page app” (kind of), using
> pretty much standard React.js patterns (it is hoped that while React.js is
> the glue of blue ocean, plugin authors don’t have to be an expert in it,
> and could use something else to deliver their front end functionality).
> There is a server side API plugin called “blueocean-rest” which provides a
> http/REST-like api that helps drive the GUI (it too is extensible, but it
> just builds on stuff 

Re: Patching Groovy?

[nicolas de loof]

Based on the high number of forked library Jenkins do already rely on,
which make maintenance a hard job to keep in sync with upstream / get
patches approved, I'd prefer to postpone groovy update and wait for 2.4.7

2016-05-20 20:14 GMT+02:00 Daniel Spilker :

> OK, sounds reasonable. Option 3 it is. Can someone give me the necessary
> permissions (see above)?
>
> Daniel
>
> On Fri, May 20, 2016 at 7:47 PM, Andrew Bayer 
> wrote:
>
>> I'm pro #3 given timeframes - it'll be at least a week or so for 2.4.7 to
>> get released (given time to get the vote started/finished, etc) at best,
>> and I'd prefer not to pull in unreleased changes we don't know we *need*.
>>
>> A.
>>
>> On Fri, May 20, 2016 at 7:58 AM, Daniel Beck  wrote:
>>
>>>
>>> > On 20.05.2016, at 16:53, Daniel Spilker 
>>> wrote:
>>> >
>>> > I would go for option 3 or 4, but I'm undecided between the two.
>>> Option 3 reduces the risk with a minimal diff. But with option 4 the diff
>>> to the official 2.4.7 should be minimal, so we could update to an official
>>> release within the LTS line.
>>>
>>> We may already be past the LTS window (decision on June 8), so 3. would
>>> be my favored approach as it's more likely that Oliver accepts the back
>>> port of patched Groovy. That said, it's ultimately up to him.
>>>
>>> --
>>> 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/A3DF5430-8B05-491D-B9BE-21ADEA2F2A15%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/CAPbPdObak8ejWCq_L7-0P77Z3NEAJeiQHrfM9QXfB%2BSabdFzOQ%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/CAKqW32B-kMY7kNORhs1y2BTC2kT6Rn5d3SBy%3DhtV9RqqocWD7g%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/CANMVJz%3D%3DAPYNpMYEgPrenoemxGBUxO%2BHg_%3DUpHmSYDogUXTSRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about the docker-pipeline plugin

[nicolas de loof]

Using Docker Custom Build Environment Plugin approach with Pipeline is
already implemented as docker-pipeline plugin.
What we'd like to investigate during GSoC is to get further, considering
limitations of the existing approach, and a docker-centric way to manage
build elasticity and customization.

2016-03-16 14:38 GMT+01:00 :

> I got it. Therefore, does it mean that I can integrate the notion of
> "pipeline as code" with the base of the Docker Custom Build Environment
> Plugin, so that we can run the pipeline steps in the container by using
> plein Docker CLI?
>
>
>
> Le mardi 15 mars 2016 18:10:24 UTC+1, nicolas de loof a écrit :
>>
>> docker-pipeline does rely on docker-exec to enter a container an run
>> commands inside it, so the jenkins slave remoting still applies to the
>> hosting node.
>> this was inspired by Docker Custom Build Environment Plugin (aka Oki
>> Docki plugin)
>>
>> Main benefit is you can run arbitrary docker image, you don't need one
>> created to host a jenkins slave. Typically, you can use an image you use on
>> your own developer workstation to reproduce a specific build environment.
>>
>> But this setup also has some limitations, one of them being you need a
>> local docker daemon on jenkins slave, as it relies on bind mounting project
>> workspace
>>
>>
>>
>> 2016-03-15 16:58 GMT+01:00 :
>>
>>> Hello, everyone!
>>>
>>> I'm working on the subject about the "Integration of Docker plugins with
>>> Jenkins 2.0 features". I have learned that the Docker-Pipeline Plugin can
>>> run the pipeline steps inside the containers by using Jenkins Slave, but
>>> i'm wondering the interest of running the pipeline steps by depending on
>>> the Docker CLI instead of the Jenkins Slave remoting in the images?
>>>
>>> Thanks,
>>> Guobao
>>>
>>> --
>>> 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/486afcb3-7a38-45e9-823b-74710dd6e041%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/486afcb3-7a38-45e9-823b-74710dd6e041%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/a3f065e1-5a60-4a35-a4b2-7202d8f17913%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a3f065e1-5a60-4a35-a4b2-7202d8f17913%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CANMVJznMCR48SXNPn2e1JnN0QDXmr4Dq0fjCvsC1nBmB5vYhcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question about the docker-pipeline plugin

[nicolas de loof]

docker-pipeline does rely on docker-exec to enter a container an run
commands inside it, so the jenkins slave remoting still applies to the
hosting node.
this was inspired by Docker Custom Build Environment Plugin (aka Oki Docki
plugin)

Main benefit is you can run arbitrary docker image, you don't need one
created to host a jenkins slave. Typically, you can use an image you use on
your own developer workstation to reproduce a specific build environment.

But this setup also has some limitations, one of them being you need a
local docker daemon on jenkins slave, as it relies on bind mounting project
workspace



2016-03-15 16:58 GMT+01:00 :

> Hello, everyone!
>
> I'm working on the subject about the "Integration of Docker plugins with
> Jenkins 2.0 features". I have learned that the Docker-Pipeline Plugin can
> run the pipeline steps inside the containers by using Jenkins Slave, but
> i'm wondering the interest of running the pipeline steps by depending on
> the Docker CLI instead of the Jenkins Slave remoting in the images?
>
> Thanks,
> Guobao
>
> --
> 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/486afcb3-7a38-45e9-823b-74710dd6e041%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/CANMVJzk1GvsHH5%3DiwjaV1NwU0XcqW%3DYYdEPg1m%2BFAQ5giRwP3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Maintenance of S3 Plugin

[nicolas de loof]

 Added Jimilian as a GitHub committer for repository
s3-plugin

Thanks for taking care of this plugin

2016-03-15 8:19 GMT+01:00 Alex A :

> Hi everyone!
>
> In our company we are using Jenkins and S3 plugin very hard. We already
> have a lot of improvements
>  for S3. But this plugin
> are not maintained anymore. So, we decided to take ownership on it and to
> share our improvements with community.
>
> Can I take ownership of this plugin?
>
>
> User: Jimilian
> Github: https://github.com/Jimilian
>
> Br, Alex
>
> --
> 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/836cd6f1-dcae-4131-86b0-cbe52db9a623%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/CANMVJzm339CqnNpbA%2BJJPGtJ-nGf7dr3OabvuJHjsizVoNbVbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: One-Shot Executors

[nicolas de loof]

we want to distinguish error due to job misconfiguration (bad docker image
ID for sample) and infrastructure issue (no available resources)

2016-03-10 19:58 GMT+01:00 Suckow, Thomas J :

>
>
> On 3/9/16, 12:40 PM, "jenkinsci-dev@googlegroups.com on behalf of Jesse
> Glick" 
> wrote:
> >
> >Or just fail the build and the next one should work.
>
> I just don't want to have to kick builds when a normal slave would "just
> wait". Our cloud is also far from 99.9% uptime.
>
> --
> 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/D30701C3.2858A%25thomas.suckow%40pnnl.gov
> .
> 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/CANMVJzk%2BaX0-1te7s8hg5_xnDE5o%3D0Gtmvkcqy40v7Q%2Bofkj1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[GSoC2016] Interested in Integration of Docker plugins

[nicolas de loof]

Hi !

Yoann and I, who applied as mentors on this topic, both live in Rennes, so
we could easily discuss this in mode details.

Our plan is to investigate how Jenkins could better rely on a Docker
infrastructure. We already have some proof-of-concept code, but now need to
inject into jenkins-core the missing (if any) hooks to offer a clean
implementation. This is the main part of our proposal for GSoC



2016-03-10 12:30 GMT+01:00 :

> Hello, everyone!! Sorry to present myself after the discussions. Because i
> had the exam in the beginning of this week.
>
> My name is Guobao. I'm the student of Polytech Nantes, and i am studying
> Informatique(SILR: système informatique, logiciel et réseaux) in the 4th
> year. I am following a project by using Docker, Docker Swarm for the
> deployment of the server Mosca(which is a MQTT server for IOT). I also have
> the competence of JAVA. For me, i have the enthusiasm at Docker and Java.
> So i hope i can have more information about the project of Integration of
> Docker plugins with Jenkins 2.0 features. By the way, i consider this
> project as my internship this year, so i'm not sure this project is
> possible for me or no.
>
> --
> 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/09bc9ecf-3422-424d-8db0-8f7d296ef1ae%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/CANMVJz%3DPyJafvbou6j2igOqXNnafzVbwwCUY3cP%3DztojhPX5jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: One-Shot Executors

[nicolas de loof]

please see
https://github.com/jenkinsci/one-shot-executor-plugin/commit/86c632091391e3204432a8c7d1a18bb48b3a66e3

basically, this on let the provisionner keep a task in the Queue when it
can determine it hasn't enough resources to run extra slaves.
this can be used to prevent overload, or allocate some extra physical nodes.

2016-03-09 23:32 GMT+01:00 nicolas de loof :

> "
> I do agree that certain issues should fail immediately (image not found).
> Certain other issues should perform exponential backoff (Cloud
> infrastructure down). Provisioning limits could be annoying though, would
> be interesting if they could be left in the queue until Jenkins side
> provisioning limits are not violated. I am not sure how to handle an
> environment like Kubernetes though where other entities may be utilizing
> resources and you have to "share".
> "
>
> This is something we have in mind. Provisioner could wait for available
> resources before it creates a Slave, leaving the task in the queue with a
> LabelAssignment waiting for matching executor. Would anyway need to let the
> Run start *then* create the slave, which means some race condition could
> appear and the required resources aren't available for this Slave to start
> even they were, few ms before - or we need some way to reserve resources on
> the infra, which then would significantly limit the available
> implementations. Maybe then we could cancel the Run, as we run early in
> it's lifecycle, and re-schedule it as a task in the Queue, claiming the Run
> never existed ?
>
> 2016-03-09 21:40 GMT+01:00 Jesse Glick :
>
>> On Wed, Mar 9, 2016 at 11:52 AM, Suckow, Thomas J
>>  wrote:
>> > Certain other issues should perform exponential backoff (Cloud
>> > infrastructure down).
>>
>> Or just fail the build and the next one should work.
>>
>> > It could also handle the logic of some users wanting to configure
>> slaves on
>> > a per job basis.
>>
>> If you mean “configure Docker images on a per-job basis”, this is
>> addressed by both the Docker Custom Build Environment and Docker
>> Pipeline plugins, both of which ought to move toward using this new
>> infrastructure.
>>
>> --
>> 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/CANfRfr3ycEVavhfm2Kuj5pOB5fkPF6vaOJfb6Zu-89y%2BQRm95g%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/CANMVJz%3DQNuogSJvuUMWR9RbjczW1fAd8pAJD9aa0Lk0H5aFwAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating from cloudbees docker build and publish v1.0.1 to v1.1 causes docker build failures.

[nicolas de loof]

looks to me the plugin didn't correctly handle legacy data migration

in 1.0 dockerfilePath was used to store the build context - as there was
only one possible dockerfile the variable name looked good
in 1.1, support for --file was introduced by changing the meaning of this
field, and adding buildContext to replace it on its initial role
so the confusion


see
https://github.com/jenkinsci/docker-build-publish-plugin/commit/61e55dce1d4c78a21740ba98d271ddcb7369d741

seems it's too late now to change this, will need to reconfigure the job.

2016-03-09 23:28 GMT+01:00 Michael Neale :

> OK, interested in how things are when you upgrade docker.
>
> I'll take a closer look at the confusion around Dockerfile name vs path.
>
>
> On Thursday, March 10, 2016 at 7:18:49 AM UTC+11, Liam wrote:
>>
>> So our Jenkins machine is running docker 1.7.1 atm. We're going to
>> upgrade to 1.10 shortly.
>>
>> I don't think that we actually need to change anything, and it's not like
>> we can rewrite past versions or anything, for me it's more about providing
>> a working migration path forwards.
>>
>> Even if that takes the form of a script or something, that's totally fine.
>>
>> On Wednesday, 9 March 2016 13:37:24 UTC+13, Michael Neale wrote:
>>>
>>> In the short term, I don't think you are missing out on anything by
>>> using 1.0 while you work out what docker version.
>>>
>>> May need to adjust this to work more as expected.
>>>
>>> On Wednesday, March 9, 2016 at 10:57:53 AM UTC+11, Liam wrote:

 I'm not sure what version of docker is running on the Jenkins machine
 at the moment. I'll find out, but that may take a little while.

 Yes, you're correct that bs-api is the directory containing the
 dockerfile (the path). In v1.0.1 it was treated as such, but now it's
 treated as the path to the Dockerfile (the --file flag).

 We're not really in a position to be able to manually adjust this for
 all of our builds, since we've got loads that use this property.


 On Wednesday, 9 March 2016 12:05:36 UTC+13, Michael Neale wrote:
>
> Some of these changes were due to changes in docker itself - what
> version of docker are you running?
>
> Yes, I suspect the meaning is a subtle change.
>
> So in the past bs-api I guess would have been the PATH.
> The latest cli:
> https://docs.docker.com/engine/reference/commandline/build/
>
> So according to this, in 1.1 of the plugin, bs-api would be the name
> of your "Dockerfile", which is probably not what you mean? the bs-api was
> the directory that had the Dockerfile in it before if I am right?
>

>
> On Wednesday, March 9, 2016 at 9:14:45 AM UTC+11, Liam wrote:
>>
>> We're using
>> https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Build+and+Publish+plugin
>> to do our docker builds.
>>
>> I've tried to update from v1 -> v1.2, which caused previously
>> successful builds to fail. I went back through and isolated the issue to 
>> be
>> the jump from v1.0.1 to v1.1.
>> I didn't alter any of the build configuration during this process.
>>
>> Looking at the logs, it seems like the commands are run differently,
>> despite the lack of change in configuration:
>> v1.0.1:
>>
>> docker build -t lfn3/bs-api:142 --no-cache=true bs-api
>>
>>
>> v1.1
>>
>> docker build -t lfn3/bs-api:141 --no-cache=true --file=bs-api 
>> /var/lib/jenkins/jobs/docker-bs-api/workspace
>>
>>
>> It appears that the parameter that was previously treated as the docker 
>> context dir is now passed as the docker file-path.
>>
>> It seems like the field was mis-named in v1.0.1: "Directory dockerfile 
>> is in", and I'm guessing it was renamed to something like "Dockerfile 
>> name" and a separate context dir was introduced?
>>
>> --
> 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/e0483afc-b782-49c3-a4ac-534c13ceaa6d%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/CANMVJz%3Dd5tYz%2B1ScGzWtZL9aDjT41_Yab1r8DMY-K%3DXfXgYi-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: One-Shot Executors

[nicolas de loof]

"
I do agree that certain issues should fail immediately (image not found).
Certain other issues should perform exponential backoff (Cloud
infrastructure down). Provisioning limits could be annoying though, would
be interesting if they could be left in the queue until Jenkins side
provisioning limits are not violated. I am not sure how to handle an
environment like Kubernetes though where other entities may be utilizing
resources and you have to "share".
"

This is something we have in mind. Provisioner could wait for available
resources before it creates a Slave, leaving the task in the queue with a
LabelAssignment waiting for matching executor. Would anyway need to let the
Run start *then* create the slave, which means some race condition could
appear and the required resources aren't available for this Slave to start
even they were, few ms before - or we need some way to reserve resources on
the infra, which then would significantly limit the available
implementations. Maybe then we could cancel the Run, as we run early in
it's lifecycle, and re-schedule it as a task in the Queue, claiming the Run
never existed ?

2016-03-09 21:40 GMT+01:00 Jesse Glick :

> On Wed, Mar 9, 2016 at 11:52 AM, Suckow, Thomas J
>  wrote:
> > Certain other issues should perform exponential backoff (Cloud
> > infrastructure down).
>
> Or just fail the build and the next one should work.
>
> > It could also handle the logic of some users wanting to configure slaves
> on
> > a per job basis.
>
> If you mean “configure Docker images on a per-job basis”, this is
> addressed by both the Docker Custom Build Environment and Docker
> Pipeline plugins, both of which ought to move toward using this new
> infrastructure.
>
> --
> 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/CANfRfr3ycEVavhfm2Kuj5pOB5fkPF6vaOJfb6Zu-89y%2BQRm95g%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/CANMVJzke%3D_zx5%2BupiXp7ZBwnzwCLmvcnnUr-Hms%2BvGJ9ii13tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.