Re: Proposal: New twitter contributors

[R. Tyler Croy]

(replies inline)

On Thu, 02 Jan 2020, Oleg Nenashev wrote:

> Update here: We are still waiting for permissions to be granted by Tyler.
> IIUC the current setup, the Tweetdeck permission management is done through 
> his
> account, and that the permission transfer cannot be performed by other
> contributors


I had to get around to logging back in as the Jenkins user to add these, but
they've since been enabled :)


May your typos be minimal, and your retweets be plentiful!

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20200102201311.e57jkfakt42hpnxn%40grape.


signature.asc
Description: OpenPGP digital signature

Re: Proposal: Deprecating/Removing OS X packaging for Jenkins

[R. Tyler Croy]

(replies inline)

On Tue, 19 Nov 2019, Oleg Nenashev wrote:

> As you probably know, there is ongoing work on automating Jenkins Core 
> releases
> within the Jenkins infrastructure. Apart from Linux and Windows distributions,
> there is also a OS X installer which is being produced for each Weekly and LTS
> release in the current release environment ([1]download link). There are also 
> a
> [2]homebrew formula being maintained by the HomeBrew community, these packages
> are even listed in our [3]installation guide.



I'm strongly in favor of removing the macOS packaging.  From a time management
and benefit standpoint, I don't think its worth any time to support it.


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20191119215435.fprugebmzkhs5jqa%40grape.


signature.asc
Description: OpenPGP digital signature

Re: [Jenkins-infra] Requesting Admin access in the jenkins-infra organization

[R. Tyler Croy]

(replies inline)

On Fri, 01 Nov 2019, Oleg Nenashev wrote:

> 
> I do not understand how come we have such repos there, but it is enough for 
> me to dismiss my request for full administrative access. I do not want such 
> kind of responsibility ATM, because my laptop is not configured for such 
> level of sensitive info. My sole goal is to help the infra team and to 
> facilitate contributions to the infra.
> 
> Instead of that, I kindly ask to create a new team with Admin access in 
> Jenkins infra components like ci.jenkins.io, update centers, IRC bot, K8s 
> charts, and so on. I also ask to create an empty .github repo and grant the 
> new team access there as well.



I don't have a problem with either direction. I'm not as familiar with you on
how .github repositories are used, how close to admin-like permissions across
the org do changes to that repository become?



--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20191102201404.z5jjlsklkbchca6s%40grape.


signature.asc
Description: OpenPGP digital signature

wiki.jenkins.io is now effectively in read-only mode

[R. Tyler Croy]

Our primary wiki has been struggling lately without sufficient or motivation
from anybody in the infrastructure team to fix it or keep it alive. We have
also seen increased spam attacks, which must be pain-stakingly cleaned up.

As a stop-gap measure I have restricted adding pages, comments, and attachments
to administrators. I _believe_ edits will still work by users, but it's only a
matter of time before spammers start defacing plugin pages and things like
that.


Thanks to Oleg (I believe) plugins.jenkins.io can pull README.mds from GitHub
and display those inline. I strongly encourage everybody to consider this
approach for their plugin pages. I don't know how much longer we can keep
Confluence alive.



Please jump into #jenkins-infra on Freenode if you have any questions, or feel
like yelling (praise) at me about this.




Toodles


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/jIfr-rfo9WizBut_ApNLwBufPREsEQ3qkybbZR9ao9ITNQhi_xeTcwXcQf69xNy7MMc6kKB1du4-sutr6qedHP70Fxnx-4TsNLg0EkX2aFY%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Re: 2019 Elections: List of nominees

[R. Tyler Croy]

(replies inline)

On Wed, 09 Oct 2019, Kohsuke Kawaguchi wrote:

> As per [1]the post, here's the nominees to various positions:


Thanks to Tracy and Kohsuke for pushing this along, we're definitely overdue :)


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/rnO0rPoWGSC6rNlMuR7hk6VZzkxQQ1swfz8incFZfzhPwl8CWrVZyLlS6FPo73XwzZDSSFBVEnXl3P7gvm1gwcxIC8jGfJrixgevBoamGJs%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Re: Trademark sublicense request: Jenkins Master Class

[R. Tyler Croy]

(replies inline)

On Wed, 09 Oct 2019, Parker Ennis wrote:

> On behalf of CloudBees, I’d like to request permission to use the following
> name with ‘Jenkins’ in it:
> 
>   • Jenkins Master Class
> 
> "Jenkins Master Class" will be a series of educational webinars hosted by
> CloudBees that invites experts from both the Jenkins community and CloudBees 
> to
> team up and share their knowledge with others. The intent is to host 10+
> webinars, or "courses," with a duration of about an hour each released on a
> monthly cadence. They will be recorded for future use. Here's a loose [1]
> example of the concept from which we're drawing inspiration.



The "test" we have typically applied to such requests in the past was whether
the use of the mark was pecific to Jenkins, as opposed to including other
non-Jenkins applications/products.

For example, I have no problem with this so long as the content of the "master
class" are specifically around Jenkins as it is understood by the open source
community, i.e. open source plugins and core, etc.

If this "master class" were to contain Jenkins-based commercial products, such
as CLoudBees Core, then I would have an objection to the use of the Jenkins
trademark for the effort.


Knowledge sharing is certainly a noble goal, but for the use of the Jenkins
mark, the scope should be necessarily limited.



Toodles
---
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/RsYEboXMRk5QGxcXH0moxY7pT4lEdZ636ceepYhZL0XiTh9Ep5xNzwdrKd-JelWpcKE13oh0ufLhApxcHtZpypn7eoZ3dPX7b2Xc2SyriLc%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Ongoing partial outage on ci.jenkins.io

[R. Tyler Croy]

I'm writing this to let you all know that we're experiencing on on-going
partial outage on ci.jenkins.io which is affecting the ability of the system to
process pull requests and merges to plugins, core, etc.

Starting sometime yesterday (2019-08-14), all attempts to provision Azure VM
agents began failing with Azure API errors. As such **no** Azure VM agents are
provisioning. Fortunately Azure Container Instances are provisioning, so now
might be a good time to try them out for pull requests you wish to validate:
buildPlugin(useAci: true) will utilize those agent types for the Linux branches
of the pipeline.


I have some backchannel communication going on with some teams at Microsoft
about the issue, but at this time I do not have an estimated time for
resolution.

The underlying cause appears that the Azure REST APIs that ci.jenkins.io are
relying on are rather old, no longer supported, and something may have changed
to cause them to start failing to validate the "Deployments" (Azure
terminology) generated by the plugin which integrates Jenkins to Azure. If my
suspicions are correct about the fix, it will require some new plugin builds
and releases, which would mean we're likely a day or two away from the issue
fully being resolved.


I will update this thread as more information becomes available.



Cheers
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/XpykJ0xr90L8gOeOuSJrgInLG4-C2Boxc33WUM1oCbqLPbzETlUUL-ZuITnnLDQm5t7HcWobPvumZhdBAad2jrQC1Nk-_Yd7Dhdbi2yaNR8%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Re: Jenkins GSoC Budget update + JEP-8 confirmation for 2019

[R. Tyler Croy]

(replies inline)

On Wed, 31 Jul 2019, Oleg Nenashev wrote:

> There would be a number of requests to get all the topics covered, and it 
> would
> require a lot of overhead in the developer mailing list. Last year we have
> suggested [4]JEP-8 which basically lets GSoC org admins to manage and approve
> the GSoC budget. The JEP was put on ice due to the CDF discussions, but at the
> moment CDF does not cause changes in how GSoC operates, we will be using SPI 
> as
> it was discussed with the Jenkins board.
>
> My suggestion is to make a blanket JEP-8 approval for GSoC 2019 so that we can
> operate on this front easily. I suggest the following:
>
>   • In 2019 GSoC org admins manage the GSoC budget according to [5]JEP-8 
>   • GSoC org admins are expected to have not less than 1000 USD of the 
> leftover
> budget for 2020. It will be used for funding of GSoC activities if needed
>
> WDYT?


I think this is a reasonable approach, but I would like it to be clear who = the
GSoC Org Admins are, and a paper trail for budget being discussed and appro=
ved.

I'll be around in the governance meeting today, and I can repeat this there= as
necessary :)


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/i9JyB1pE1qWV0jNWFP15aeIhwJNMxb8oo3_tf9O-WHQ995LNt-vI1_V6JLeXRrjkllqw2LtpB0D1TthP8sF8yiqhs5nVGT4ykM3pABXGwJc%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Re: ANN : Jenkins Governance meeting on July 31st

[R. Tyler Croy]

Thanks for sending the announcement Oleg, I'll be there :)


On Mon, 22 Jul 2019, Oleg Nenashev wrote:

> Hi all,
> 
> As you probably know, Jenkins Governance meetings have been inactive for a
> while. It is not a big problem for Jenkins LTS releases and SIG updates, they
> work well in the Developer mailing lists. LTS baseline selection could be also
> moved to the developer list. But we still have the expense approval process
> which requires discussion in the developer mailing list. There are some 
> pending
> budgeting items for GSoC and Community Bridge, and we agreed to run a Jenkins
> Governance meeting on July 31st.
> 
> If you have any requests you would like to get approved, please start a dev
> list thread and add topics to the agenda here: [1]https://wiki.jenkins.io/
> display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-July31
> 
> Best regards,
> Oleg
> 
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to [2]jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit [3]https://groups.google.com/d/msgid/
> jenkinsci-dev/63c1a3dc-7eb5-4c3a-be42-401ba8e1158f%40googlegroups.com.
> 
> References:
> 
> [1] 
> https://wiki.jenkins.io/display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-July31
> [2] mailto:jenkinsci-dev+unsubscr...@googlegroups.com
> [3] 
> https://groups.google.com/d/msgid/jenkinsci-dev/63c1a3dc-7eb5-4c3a-be42-401ba8e1158f%40googlegroups.com?utm_medium=email_source=footer
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/x0xUzxTRENKUwdCV7dN9fsc5sDJNnWSl7W_amFv9lcWjCAf9-KvspF4Gqro0YmJMuqPtwPqFU_d7uwROwKo60v3K7cYoNo-jB3SctTL3GTA%3D%40brokenco.de.


signature.asc
Description: OpenPGP digital signature

Re: What keeps CI tests from running on this Jenkinsci repository?

[R. Tyler Croy]

(replies inline)

On Fri, 12 Jul 2019, 'Benjamin Beggs' via Jenkins Developers wrote:

> Terrific, if you can do that it would be great. :)


Sorted:
https://ci.jenkins.io/job/Plugins/job/enhanced-old-build-discarder-plugin/


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/jsmC6UqW7LD1yWCXvdIw4qROIzGn2n5LxxZAlKS3fir9F1oCrYQVSYwtTxEC8YqR3p8l6ZcWUWTUKsGJsRA04P4UzWg5vCGnvC-_zDuSsD4%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: What keeps CI tests from running on this Jenkinsci repository?

[R. Tyler Croy]

(replies inline)

On Fri, 12 Jul 2019, 'Benjamin Beggs' via Jenkins Developers wrote:

> Does anyone know why CI tests aren't running on pull requests for this
> repository?
> [1]https://github.com/jenkinsci/enhanced-old-build-discarder
>
> I've added a Jenkinsfile to the source root directory on the master branch 
> ([2]
> https://github.com/jenkinsci/enhanced-old-build-discarder/blob/master/
> Jenkinsfile). No CI is coming up for my latest PR ([3]https://github.com/
> jenkinsci/enhanced-old-build-discarder/pull/3).
>


The directory name doesn't match the convention used by most (all?) the other
plugins which is $(name)-plugin.git, and thus it fails the regular expression
used by our Organization Folder.


I can change the repo name to match if you'd like
>
>
>
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/O33ofubDhAEuPfpt0hu0jHmIXvmo50h00H5aJfWBS1NzNGWtG0u1G4UdD-vK60syYOB_XwODXCURTTT0oZUCHdLX7h_0pFbIuRxLv-9ZZZs%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Why don't disable DNS Multicast by default?

[R. Tyler Croy]

(replies inline)

On Sun, 26 May 2019, Daniel Beck wrote:

> 
> 
> > On 17. May 2019, at 12:08, Francisco Javier Fernandez 
> >  wrote:
> >
> > I'm wondering if it's worth to change the default behaviour and disable it, 
> > so anyone who wants this feature enabled should use the 
> > hudson.DNSMultiCast.disabled system property. It does not seem to be a 
> > widely used feature.
> 
> IIUC, the rationale for having these installed is for IT staff in large 
> organizations to be able to discover Jenkins instances on their network, 
> typically operated by developers wanting/needing to bypass red tape. 
> Identifying these services is the first step to improve 
> standardization/operations.
> 
> For that reason, anything but core-bundled, enabled-by-default means the 
> feature might as well not exist.



I think it's worth removing the feature. Frankly, if somebody needs multicast 
to find
a Jenkins server on their network, then they should probably not be considerd
IT/network admins. Finding a Jenkins instance in a big network is trivially
easy, as cryptominers have demonstrated quite effectively over the past couple
years ^_^


IMHO this is not a feature, but technical debt that's best removed.


Cheers

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190526171559.fhmtb63o7n66lbm6%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: Is there Python support for ci.jenkins.io plugin builds?

[R. Tyler Croy]

(replies inline)

On Thu, 16 May 2019, Chris Kilding wrote:

> I was able to substitute in the fabric8 Docker Maven Plugin to run Moto. It
> seems to work fine on the Linux build agent, but the Windows agent doesn’t 
> like
> it (no Docker host or docker.sock available.)
> 
> Is there another way to get Docker support on the Windows agent, or is this 
> ‘in
> the works’ for the future?


Neither unfortunately. There is an infrastructure ticket which I don't have any
plans to get to: https://issues.jenkins.io/browse/INFRA-1400




--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/h8ekP_4C4XNiCREsuXDB-OSeihblF-Vlx7Cgil7rQLyirqSDJZdeg5ToeRNSbFT9023KLpj-0EJ78Xwp7CCENla3BkgJzxJFzaEfwzQ82LM%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Is there Python support for ci.jenkins.io plugin builds?

[R. Tyler Croy]

(replies inline)

On Wed, 15 May 2019, Chris Kilding wrote:

> Yep, that sounds reasonable. (I had suspected as much - there would be no end
> to the possible system packages that plugin developers might want.)
> 
> Do the ‘docker’-labelled Jenkins agents support the usual ‘dockerfile’
> directive to let the build define a Docker image ad-hoc? Or do all images have
> to be pre-packed and hosted on a registry?


The 'docker' labeled agents are all full VMs and the pipelines do have full
access to the Docker socket, so Dockerfiles should be fine.



--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/WOA6p30q5mgycsLk5VZWSBiSey1OiqQD4rFxG5C_2j1RKEGXDJYRZKpdymzN5Sl2z8BnWWsD7k9XBQvtlLx6PX8FVVDESCa8G4-N2vd-Xng%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Is there Python support for ci.jenkins.io plugin builds?

[R. Tyler Croy]

(replies inline)

On Wed, 15 May 2019, Chris Kilding wrote:

> My plugin uses an external dependency, Moto (the AWS mock server) for its
> integration tests.
> 
> Moto is written in Python, installed with Pip, in a virtualenv. It can be used
> either directly (where we must do the pip install ourselves) or through the
> Java wrapper Localstack (which does little more than run those same commands
> for us).
> 
> It appears that ci.jenkins.io agents have *some* kind of Python toolchain
> installed, but it’s limited: there is no ‘pip’ and maybe no 
> ‘virtualenv’
> either.
> 
> Do any other Jenkins plugins use Python or Python dependencies, and if so how
> are Python/Pip/Virtualenv set up in their builds?


The fact that there is Python is incidental more than anything. We will not be
installing any system packages on agents however, so I suggest working out how
to use Docker containers to meet your needs, as those are definitely supported
on machines with the 'docker' label.

Cheers.

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190515163618.jgyeizkbqejmhbpg%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: Request the access permission of repo jenkins.io

[R. Tyler Croy]

(replies inline)

On Wed, 15 May 2019, Rick wrote:

> I can see I'm a member of copy-editors. But I still cannot merge any PRs of
> jenkins-infra/[1]jenkins.io

As Olivier mentioned, copy-editors do have write permissions to this repo, but
the branch protection was preventing that group from merging. I believe that
was a mistake on my part from some long time ago.

I've allowed copy-editors to write to the master branch.


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190515163408.jcxd5xttv2qdtnip%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: Request the access permission of repo jenkins.io

[R. Tyler Croy]

(replies inline)

On Sun, 12 May 2019, Rick wrote:

> Hi team,
> 
> I would like to request the access permission of repo [1]jenkins.io.
> I'm the leader of [2]Chinese Localization SIG. I believe it will be helpful to
> review and merge PRs which is related to the Chinese Localization SIG faster.


I have added you to the copy-editors group to make this ismpler to manage.

I trust that you will focus your merges in the appropriate area of
responsibility.


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190513133459.tvftc4vfjn4a4fve%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: [INFRA-2086] - Switching ci.jenkins.io builds to AdoptOpenJDK

[R. Tyler Croy]

(replies inline)

On Thu, 02 May 2019, Jesse Glick wrote:

> On Thu, May 2, 2019 at 9:12 AM Oleg Nenashev  wrote:
> > The releases are distributed from GitHub, so they are more stable even if 
> > we continue downloading JDKs by URL.
> 
> It ought to be easy to configure the (nginx?) mirror running in Azure
> for use by ci.jenkins.io builds to also mirror AdoptOpenJDK releases,
> so we are not transferring huge archives from GitHub???s download
> servers on every build.


This was discussed a bit during the infra meeting this past Tuesday, and we
will not be mirroring GitHub's CDN. I am not worried about hitting their edge
caches for releases. As Oleg pointed out in a ticket earlier: if GitHub is
down, ci.jenkins.io won't be very useful anyways :)


Of course, the infra team needs less services to babysit, not more.

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/fcubOHM2qLfFo5v5aNMn7VcCSy7HxG7Oii9sbTzv7rKCm-jMP0qrB5EE2_KLspocGgSEWSrMeqbkT2U1IhDxUp0HngiAD5uknQqNjwx32wI%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Request for Admin permission on https://github.com/jenkinsci/

[R. Tyler Croy]

Sounds good to me, prepare to be cursed with more responsibility. :)



--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/tOGG6fxM4sTg5oLfuVmJ0totH3Rz2vBHSTyFdIySj23rZivs56fnuhjpk2To-VlOPnc-2qJ7aCe2FNeibfDLFWmRmFBVqkh2-4KWm0LqVr4%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

ANN: Jenkins is joining the Continuous Delivery Foundation

[R. Tyler Croy]

We have already discussed this quite a bit in prior meetings and email threads,
but today the news was made official and the Continuous Delivery Foundation
(CDF) was launched.

See Kohsuke's blog on the topic:
https://jenkins.io/blog/2019/03/12/cdf-launch/


I'm very excited for our future with the CDF, and shared some of my own
thoughts here: https://brokenco.de/2019/03/12/announcing-the-cdf.html


Thank everybody for their hard work leading up to this point, and I'm looking
forward to starting the formal process of transitioning project assets to the
our new home, and investing in the future growth of the project!



Cheers

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/P4v6jL_RIynoY_wKZbHJPBXIOQ5hHzNN3VCQZeZQmKOgh6tlva1f49wp_JHkOOmtMZnEM9ChfVLFxS07ViXJ_cS1mgHUktAJh4qC0CMFbxs%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: jaxen

[R. Tyler Croy]

Archival in GitHub sounds reasonable to me, I presume we won't do anything in
Artifactory?


If everybody's fine with this, either an Infra ticket, or one of the other
github admins can take care of this easily.


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/RsFhACx0PiBp9J6JkjL8PtdkBh_I_V8VMC7FWrx_56uzkBNanScKYiMOy3Wa4HRf0RKPUG2T_9dFGX5Hp_cOoNRRXYfoMmETbiV_tfAiaNg%3D%40brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Switching to CentOS for Jenkins Docker base image

[R. Tyler Croy]

(replies inline)

On Wed, 27 Feb 2019, Olblak wrote:

> But I am wondering, instead of going with Centos why not using this PPA 
>  with ubuntu? 
> This would imply a smaller breaking change

I do not believe that Jenkins should rely on any PPA (Personal Package
Archive), they have a tendency of growing stale unlike mainstream official
packages.



--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190227162854.h3ykv36emu4wawwf%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSS] Switching to CentOS for Jenkins Docker base image

[R. Tyler Croy]

(replies inline)

On Tue, 26 Feb 2019, Matt Sicker wrote:

> Based on the details regarding Debian and Ubuntu's poor maintenance of JDK
> packages, I'd support using a different distro like CentOS. That certainly
> pushes myself away from defaulting to ubuntu or debian for Java Docker
> images.


Agreed! I think this is worthwhile to do. The first responsibility IMO of our
containers is to provide the most stable and secure Jenkins environment for end
users.

We already maintain an Alpine image, to where if there are people depending on
a Debian-based image, making that available as another set of tags is also
always an option. 


+1

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190226223130.wbcx2dr6ln5lf2g4%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

[R. Tyler Croy]

I'm game for experimenting with this :D

On Thu, 21 Feb 2019, Oleg Nenashev wrote:

> Dear all,
> 
> I would like to follow-up on the Dependabot request from Jesse Glick in
> INFRA-1975 . Dependabot
>  is a service for automated dependency updates
> which supports many languages/tools, including Maven, Docker and Gradle
> which are being heavily used in Jenkins.
> 
> Dependency management is a problem in Jenkins, because we have hundreds of
> repositories with many dependencies there. Maintainers spend a lot of time
> on managing dependencies, and sometimes it leads to ancient dependencies in
> components. Especially in the development tools which "just work". By
> automating dependency updates we could give maintainers more time to focus
> on other tasks.
> 
> Dependabot is one of the engines we could use for dependency management. It
> is free for open-source projects, and it is a SaaS application which can be
> almost completely managed from GitHub. It can just create pull requests or,
> if we want, implement validated merge with help of ci.jenkins.io. No
> special infrastructure required, and this is an advantage for us. There are
> other implementations (including UpdateBot
>  by Fabric8/Jenkins X which has a
> Jenkins plugin), but it would require more efforts to deploy the
> infrastructure. It could be considered in the future if we want to have
> Jenkins-powered update management in the final implementation.
> 
> My proposal would be to enable Dependabot for a *limited number* of Jenkins
> repositories so that we can experiment with it. I propose to focus on
> development tools and pre-1.0 projects only for now so that we can
> experiment with flow without a risk of impact on components being used in
> production in the Jenkins project. And we will be setting up auto-updates
> only for projects with existing test automation.
> 
>- Jenkinsfile Runner - Example PRs in my local repo
>
>- ci.jenkins.io-runner - Example PRs
> (bot was
>disabled after moving the repo)
>- plugin-pom - Example PRs in my local repo
>
>- maven-hpi-plugin - Example PRs in my local Repo
>
> 
> More repositories can be added if somebody is interested to participate in
> the Dependabot evaluation. If there is a positive feedback after the
> initial evaluation, we could proceed with creating a JEP to define the flow
> and the usage/administration policies.
> 
> What do you think?
> 
> Thanks in advance,
> Oleg
> 
> -- 
> You received this message because you are subscribed to the Google 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/CAPfivLA1W66hN6PmaQaBUai2MJSo1nnWJA1y59tcJQskEPrMvA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190221161048.2imlqsgphzjf7nnf%40grape.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: 2 weeks comment period for moving to the CDF

[R. Tyler Croy]

(replies inline)

On Mon, 11 Feb 2019, Kohsuke Kawaguchi wrote:

> This is the formal call for input for the decision to move the Jenkins
> project to the newly forming Continuous Delivery Foundation. (I was told
> that my earlier attempt
>  to
> just change the subject didn't create a wholly new thread, hence this email)


Thanks for splitting this out into a new thread, just to make sure people have
the opportunity to see it.


I'm personally excited for this move, so if I am unable to attend the meeting
next week due to work getting in the way, consider this my emphatic +1 in
support of Jenkins moving to the CDF!




Cheers


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190214143004.GO23906%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.

Re: 2 weeks comment period (was: Re: A new home for Jenkins)

[R. Tyler Croy]

(replies inline)

On Fri, 08 Feb 2019, Kohsuke Kawaguchi wrote:

> In FOSDEM, we organized a BOF session in which we talked a bit more about
> the CDF among 20-40 people who gathered. The response was good.
> 
> Attached is the charter of the CDF
> .
> This is the terms in which the Jenkins project is considering to move under
> the CDF. From the page 7 and onward, there's a bunch of details that
> describe the structure of the CDF.


This charter looks pretty much the same as what I originally looked at for a
"JSF" at the beginning of this process, so looks good to me! :)


> Not much of the existing structure of the Jenkins project will change.
> Committers, contributors, officers, teams, the board, and all that will
> still remain (including all the "normalization" work like voting.) The idea
> is that the board and officers of the Jenkins project will be the
> "oversight body of each TOC Project" (charter 7-b-i) and this links the
> chain of authority of the CDF and the Jenkins project. Our existing
> technical decision making process of JEP, SIG, PR, etc remain under our
> control. Again, if anyone has questions, concerns, and/or opinions, I'd
> love to hear those.


THis is important, thanks for highlighting it Kohsuke. This also reflects my
understanding of the world under the CDF. I will add that the "oversight body
of each TOC project", will also need to be in conversation with the CDF to help
set our budget to appropriately meet our needs.

Fortunately, with the CDF structure, this means we'll finally have a _real_ and
dependable annual budget, I couldn't be more excited :D


> Now, putting my board hat on, I talked with the other board members (aka
> Tyler), and if we are to pull the trigger and formalize this new home,
> given the magnitude of the proposal, we need to make a binding decision and
> record it as such. Given that this seems to be a topic that relatively
> small number of people care about, and that those reactions so far have
> been overwhelmingly positive, the board would like to set 2 weeks comment
> period ending on Feb 22nd, where we solicit anyone's organized thoughts on
> why you think we should or shouldn't move the Jenkins project under the
> proposed CDF. You can write it here, or if need be, send the board a
> private email at jenkinsci-bo...@googlegroups.com. We'll consider and
> respond to them, and provided that there still remains a significant
> consensus (like the one that we are seeing so far), then the board will
> make the binding decision.


Looks great to me, please do comment and weight in!



Toodles

--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190211144148.GV23906%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins in Outreachy May 2019 round?

[R. Tyler Croy]

(replies inline)

On Mon, 11 Feb 2019, Tracy Miranda wrote:

> The application period for the next round of Outreachy internships will
> open in a week on Monday, February 18.
> 
> Timeline  is roughly:
> Feb 18 - Mar 12: Communities sign up & add projects/mentors.
> *March 5 - last date for communities to sign up*
> Feb 18 - Mar 26: Application period for interns
> May 6 - Accepted interns announced
> *May 20 - Aug 20 - Internships period*


This timeline is overlaps with Google Summer of Code which I believe we're
already in the process of applying for. Of course we're not guaranteed slots in
GSoC, so Outreachy is certainly more of a "sure thing."
> 
The mentorship is going to be a challenge IMHO. I would love to see mentors
committed from the major companies contributing to Jenkins (and considering the
CDF), since there's oonly so much Oleg and Martin can do ;)


In general however, I'm highly supportive of another round of Outreachy
interns, but I won't be able to mentor this time around unfortunately as I'll
be likely taking on two interns this summer as is! :-!




Cheers
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190211143252.GU23906%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Too many job in ci.jenkins.io

[R. Tyler Croy]

(replies inline)

On Fri, 08 Feb 2019, Kohsuke Kawaguchi wrote:

> This excessive rebuilding behaviour also causes lots of ops overhead by
> eating up disk space.


The disk space issues we experience are due to unaddressed scalability tickets
in Jenkins Pipeline, we would be seeing them regardless.


> 
> I think we need to change the current behaviour of ci.jenkins.io.


I have been opposed to the change, but I don't consider my voice the final say
here.

My objection is that I fundamentally do not believe the green check mark on a
pull request is accurate unless the pull request is rebuilt and tested against
the latest HEAD of the target branch, even in cases of fast-forwards.


There are 88 pull requests open on Jenkins core right now, and I think it's
absolutely false to characterize anything that hasn't been updated in more than
three to six months as "valid."

I believe Daniel and Oleg have done a great job trying to keep things labeled
and organized, so we can tell that of that 88 we have 27 marked as needing more
review and 21 marked as works in progress, both going back for 2-3 years.


If core alone is causing a denial of service on ci.jenkins.io (it's not), and
we are unwilling to address the root cause, one easy solution is to add a
specific label for core only, which would be a fixed set of agents, allowing
other workloads to bypass the bottleneck.


If the maintainers of Jenkins core wish to change the settings for
core in ci.jenkins.io, I know at least one of them has the privileges to do so.


Personally, I like the probot suggestion from Oliver a lot more. Stale pull
requests are a boat anchor which drags down an open source community, and that
is IMHO the underlying problem worth fixing  here.



Cheers
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190209011052.GR23906%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.

Re: A new home for Jenkins

[R. Tyler Croy]

(replies inline)

On Wed, 16 Jan 2019, Oliver Gond??a wrote:

> Those are interesting news. Are we expecting to partner with existing
> communities around existing CD projects as a part of CDF? Are some of them
> on board with this vision or do we expect they will join us provided this
> turns out to be the right way to go? My concern is the ???Continuous
> Delivery Foundation??? feels pretty general and while getting under the
> wings of Linux Foundation is an impressive recognition of what we have
> achieved, it would be unfortunate to make an impression of claiming the
> whole field without wider consensus.


Hiya Oliver! I'll answer this since I've also been working a bit behind the
scenes with Tracy and the Linux Foundation (LF) to move this forward.

LF has been reaching out to some other projects which are what I would consider
our brothers and sisters in the Continuous Delivery space. A few of them are
projects which many Jenkins users are already very familiar with, but since a
couple of those projects are waiting for Jenkins to take the lead here, they
have not publicly discussed or committed to the idea of the CDF.


I'll have to write a blog post at some point about our path thus far, but I
originally wanted a Jenkins Software Foundation, but it was actually others
outside of the Jenkins project that _suggested_ and wanted a more broad
umbrella to support this entire space.

Suffice it to say, Jenkins is leading the way here, but we will not be the only
ones at the party! :)



Cheers
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20190117191625.zdajjrl5lkg2jx4w%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Trademark sublicense requests: Jenkins Workshops

[R. Tyler Croy]

Looks reasonable to me with the "by CloudBees" suffixes

On Fri, 14 Dec 2018, Tracy Miranda wrote:

> Hi all,
> 
> On behalf of CloudBees, I would like to request the permission to use the
> following names that use ???Jenkins???:
> 
> 1. Jenkins CI/CD Workshop by CloudBees
> This is the name for a Professional Services/training offering which is a
> workshop that helps users achieve their continuous integration and
> continuous delivery goals with Jenkins.
> 
> 2. Jenkins Jumpstart by CloudBees
> This is the name for a Professional Services/training offering which is a
> workshop that helps teams integrate and automate their CI/CD pipelines.
> 
> 3. Jenkins Virtuoso Workshop by CloudBees
> This is the name for a Professional Services/training offering which is a
> workshop that helps users learn advanced Jenkins usage and optimizations
> for pipeline automation.
> 
> 4. Jenkins X Cloud Native CI/CD Workshop by CloudBees
> This is the name for a Professional Services/training offering which is a
> workshop that helps users learn about Jenkins X and how to achieve their
> their continuous integration and continuous delivery goals for cloud native
> architectures.
> 
> I will add these an agenda item for Dec 19th project governance meeting to
> be able to get a decision there. (Please note Liam will takeover handling
> the request at the meeting as I will be away).
> 
> If you have any questions, concerns or objections, please chime in on this
> thread prior to the meeting, so that we can address them.
> 
> Regards,
> Tracy
> 
> -- 
> You received this message because you are subscribed to the Google 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/CACTaz6qj-CCaaUF%2BsS5M32LpDBbFgpUjAApU7dAnOHctOe%3D1KA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20181215174434.GU24677%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Discussion: Community Onboarding/Outreach and Advocacy SIGs

[R. Tyler Croy]

(replies inline)

On Mon, 03 Dec 2018, Tracy Miranda wrote:

> This sounds great.
> 
> My preference for structure would be as 1 SIG (called Outreach or Outreach
> & Advocacy) which is an umbrella for initiatives like GSoC, Outreachy,
> Hacktoberfest.
> 
> GSoC, Outreachy should maintain their own channels i.e. gitter, etc so
> those who want to just focus on those can do so. But then at the SIG level
> we cover more topics (as listed in the email) share best practices and
> foster wider collaboration across initiatives for those who would like to
> do so.


This sounds good to me Tracy, +1


--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

-- 
You received this message because you are subscribed to the Google 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/20181203164920.GC14598%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Defining a privacy policy for Jenkins project collected data

[R. Tyler Croy]

Howdy everybody! We recently shipped weekly releases which implement the
telemetry collection described by JEP-214 [0].

Behind the scenes of JEP-214, I have implemented and deployed a tool called
Uplink[1] for capturing and making this telemetry data accessible to Jenkins
project developers.

Before I can make this data access however, I want to get two critical policies
in place to ensure positive privacy practices:

 * Privacy Policy:  this document would explain to Jenkins users our practices
   on collecting, persisting, and analyzing data collected by Jenkins. This
   end-user education is incredibly important to me.

 * Reasonable Use Policy:  this document would explain to Jenkins contributors
   our policies for _their_ access to data collected from Jenkins instances.
   This would outline how collected data may be used, and how it may not be
   used. Contributors would be required to agree to this policy before gaining
   access to the collected data. Failure to comply with this policy would be
   something quite serious to me, and (in my opinion) would warrant revocation
   of access to collected data, and potentially other access grants within the
   project. User trust is important!


There are two privacy policies which I was recommended which may be useful in
defining our own:

 * KDE's Telemetry Policy: https://community.kde.org/Policies/Telemetry_Policy
 * MetaBrainz's Privacy Policy: https://metabrainz.org/privacy


I am curious if you all have other privacy or reasonable use policies from open
source projects which you find particularly well defined, and therefore worth
emulating?


I hope to smash this into a couple of JEPs after I get some more samples to
read through! :)


Cheers

[0] https://github.com/jenkinsci/jep/blob/master/jep/214/README.adoc
[1] https://github.com/jenkins-infra/uplink/


--
GitHub:  https://github.com/rtyler
Twitter: https://twitter.com/agentdero

-- 
You received this message because you are subscribed to the Google 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/20181017195601.GO12208%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Trademark sublicense request: TechMatrix Jenkins Platform Package

[R. Tyler Croy]

(evil top post!)

This looks reasonable to me, and I've got no problem with an umbrella of
"TechMatrix Jenkins Platform Package for X" so long as it's a legitimate
Jenkins under there :)



On Wed, 03 Oct 2018, Kohsuke Kawaguchi wrote:

> On behalf of TechMatrix, Inc. I???d like to request the permission to use the
> following name that uses ???Jenkins??? in it:
> 
>- TechMatrix Jenkins Platform Package
> 
> I have relationship with the people in TechMatrix who's doing this through
> the community (they are the key people behind Jenkins User Conference in
> Tokyo) and CloudBees (they are our partner in Japan.) Their time zone is
> not conducive to direct participation in the meeting, so I'm doing this on
> behalf of them. They have also requested "Jenkins Day Japan" event name in
> the past that got subsequently approved.
> 
> 
> To help people understand how this name is going to be used, let me
> describe a bit about the effort for which we???d like to use this name.
> 
> TechMatrix Jenkins Platform Package (TJPP) is a package of Jenkins, code
> analysis tools, testing tools and so on, integrated to work well together.
> TechMatrix is offering this commercial solution to companies who can't /
> don't want to assemble those pieces themselves, it's a way of helping
> customers get more out of pieces that TechMatrix individually sells.
> 
> TJPP is meant as an aggregated umbrella brand name for these integrated
> solutions, under which different solutions for different audience/context
> will come in as "TechMatrix Jenkins Platform Package for $SOMETHING". The
> first solution is "TechMatrix Jenkins Platform Package for Java", which
> combines CI with Jenkins and Parasoft JTest (static analysis, unit testing
> tools), further extensible to test, deployment, releases and so on. The
> possible future expansions include "for C/C++", "for C#", and so on.
> 
> Technically, I'm not sure if the approval for TJPP implicitly cover "TJPP
> for $SOMETHING" or not, but it seems pretty clear to me that if we are OK
> with TJPP, we have no reasons to object to any "TJPP for $SOMETHING", so in
> order to skip the unnecessary work for everyone, I'd like us to be able to
> give them a blanket sublicensing approval for "TJPP for $SOMETHING"
> 
> I'll put this in the next week's project meeting agenda, but given that I'm
> only proxying this, if you have concerns and questions, please raise it
> here beforehand so that they can respond in time.
> -- 
> 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/CAN4CQ4xWkyd7cOtBccqpqCL_22fhGm63A9OeW%2B5f-bH-72z5Wg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
GitHub:  https://github.com/rtyler
Twitter: https://twitter.com/agentdero

-- 
You received this message because you are subscribed to the Google 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/20181003211834.GI28842%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Add trilead-ssh2 component to the CI

[R. Tyler Croy]

i've enabled this here:
https://ci.jenkins.io/job/jenkinsci-libraries/job/trilead-ssh2/

Having trouble resolving the ticket at the moment.

On Wed, 03 Oct 2018, kuisathaverat wrote:

> thx Jesse, I will do
> 
> El mar., 2 oct. 2018 a las 17:42, Jesse Glick ()
> escribió:
> 
> > On Tue, Oct 2, 2018 at 4:08 AM Ivan Fernandez Calvo
> >  wrote:
> > > I have tried to put it in the CI by creating a Jenkinsfile like we do
> > with plugins but the component does not appear in the list of plugins in
> > the CI.
> >
> > You will need to file an `INFRA` ticket. For context:
> >
> >
> > https://issues.jenkins-ci.org/browse/INFRA-1356?focusedCommentId=320872=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-320872
> >
> > --
> > 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/JAG_0xqQF6g/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/CANfRfr3WpvvOZ6%3D%2BQdDSyZXoK1ohGuPB-EMqPQpw%3Dh6ncLuYpA%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/CAKo5QroKUZ53djFOUp-xpWT0kH%2BuVoS7SCVhamEeqZhUhzZbXg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
GitHub:  https://github.com/rtyler
Twitter: https://twitter.com/agentdero

-- 
You received this message because you are subscribed to the Google 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/20181003181123.GE28842%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins in Hacktoberfest 2018?

[R. Tyler Croy]

(replies inline)

On Mon, 01 Oct 2018, Oleg Nenashev wrote:

> Hi all,
> 
> We are live: https://jenkins.io/blog/2018/10/01/hacktoberfest/
> Let the hacking commence!


Excellent  work! Thanks for leading the charge Oleg, I'm looking forward to
some fun hacking from everybody this month :)



--
GitHub:  https://github.com/rtyler
Twitter: https://twitter.com/agentdero

-- 
You received this message because you are subscribed to the Google 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/20181002002727.GJ28434%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins participation in Outreachy

[R. Tyler Croy]

(replies inline)

On Thu, 27 Sep 2018, Andrew Bayer wrote:

> Strong +1. If we have the cash available to approve the budget now, we
> should definitely move forward. And if we don't, well, we should fundraise
> specifically for that anyway.

We definitely have ample budget for an Outreachy intern.


-- 
You received this message because you are subscribed to the Google 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/20180928021817.GC16966%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins participation in Outreachy

[R. Tyler Croy]

(replies inline)

On Tue, 25 Sep 2018, Tracy Miranda wrote:

> Hi all,
> 
> Not sure if folks have come across the Outreachy
>  programme but it is one of the leading
> initiatives around for getting more marginalised folks involved with open
> source projects. It is similar overall to Google Summer of Code, except
> relies on external contributions i.e. not funded by Google.


Thanks for taking this on Tracy, Outreachy is a good organization for us to
work with for sure!

With the bugdet request for $6500, does that cover one intern or what multiple
of interns?


Either way, I think this is a great idea and will be crossing my fingers that
we'll be able to fund some talented new contributors to the project.


-- 
You received this message because you are subscribed to the Google 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/20180925205500.GA15160%40grape.brokenco.de.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Looking forward to the Contributor Summit in SF on Monday!

[R. Tyler Croy]

I hope everybody on this list within driving distance of downtown San Francisco
joins the Contributor Summit this coming Monday (17th)
https://jenkinscontributorsummitsf.eventbrite.com/

(note: you don't have to buy a ticket to DevOps World Jenkins World to attend,
but you must register above so the event staff know where to send you)



There is a *lot* for us to talk about and share this year :D



See you there!

-- 
You received this message because you are subscribed to the Google 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/20180915194536.GT2292%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Unmaintained -- New Relic Deployment Notifier Plugin

[R. Tyler Croy]

(replies inline)

On Thu, 13 Sep 2018, blueelvis wrote:

> Hello,
> 
> There is a plugin over here  
> called
>  
> which hasn't been maintained for a long time. I tried to contact the owner 
> but didn't receive any response.
> 
> The plugin uses v1 API of New Relic which is now deprecated. The v2 API 
> features support for New Lines and other stuff. What would be the process 
> to take over this plugin or at least push out a patch?
> 
> I have a fork of mine for this plugin over here 
> .


The Adopt a Plugin process should help you get moving here: 
https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin


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


signature.asc
Description: PGP signature

Re: Community channel on Gitter

[R. Tyler Croy]

(replies inline)

On Thu, 13 Sep 2018, Tracy Miranda wrote:

> We have a jenkins-community channel on irc which is a bit in decline with
> low volume of discussion and spam-filled. I would like to suggest we
> deprecate that channel and instead start up a Gitter channel for community
> oriented discussions e.g. topics like conferences, speaking, outreach,
> diversity.


I suggest creating the channel if you haven't already and trying it out.


As the founder of #jenkins-community, I do not intend to delete the channel
until there's sufficient momentum in a Gitter-based channel if that's where
folks want to go.


For my part, I've declared bankruptcy on communication channels so don't expect
to see me join any new ones any time soon :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/20180913154817.GQ2292%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Pre-JEP check: Jenkins telemetry

[R. Tyler Croy]

(replies inline)

On Mon, 20 Aug 2018, Jesse Glick wrote:

> On Fri, Aug 17, 2018 at 4:28 PM Daniel Beck  wrote:
> > When I first brought up this idea with Tyler a few months ago, IIRC the 
> > response (from him and/or Baptiste) was there's nothing we can 
> > realistically share.
> 
> OK. I hope that changes at some point.


There are a couple key differences in requirements between what Evergreen is
doing, and what Daniel seeks:

* Storage requirements: I have no intention on making promises around data
  expiration with telemetry necessary for Evergreen. Some of the feature
  development questions I would like to answer require data over a long
  timeline in order to properly answer.  My understanding of what Daniel is
  proposing would be much more targeted and specific.

* Point of observation: with Evergreen all telemetry collection, thus far, is
  done intentionally from an _external_ point of view. In essence the
  evergreen-client is what is observing a Jenkins instance outputs or makes
  availalble to it, or to other consumers, like a standard monitoring tool.
  This principle is fairly important to me, as I'm wary of a Schroedinger's
  Jenkins problem, where instrumenting Jenkins causes differing behavior from
  what other users of Jenkins core/plugins might encounter, thereby reducing
  the value of the feedback we can provide to developers.

  My understanding of what Daniel seeks to do is a fairly tight integration
  into some fairly key aspects of Jenkins core and related tooling.
  Instrumentation which I doubt would ever be accessible to anything but the
  innards of Jenkins itself.


Personally, I think both approaches are necessary for different reasons and are
independently valid.

I suggest keeping the scope for internal instrumentation small for now without
attempting to come up with the one-global-instrumentation-approach to solve all
imaginable use-cases. I trust Daniel to implement something which can grow in
the future, and may provide a foothold for future instrumentation requirments.

We have a tendency to imagine new requirements any time sommething like this
comes up, and ultimately burden the contributor with heaps of scope, leading to
nothing ultimately being done.

IMHO the scope here is narrow enough, so from my perspective, go for it Daniel!



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


signature.asc
Description: PGP signature

Re: Growing community via a stronger Twitter presence

[R. Tyler Croy]

(replies inline)

On Fri, 17 Aug 2018, Oleg Nenashev wrote:

> I like the JEP draft in the current state.
> 
> IMHO it would be great to extend Infrastructure Requirements a bit:
> 
>- A new Tweetdeck account is created
>- Jenkins INFRA team has access to Tweetdeck so it can handle the 
>requests if needed


These two already exist.


>- The account is documented on the Jenkins INFRA wiki pages or jenkins.io
> 
> BR, Oleg
> 
> On Tuesday, August 14, 2018 at 2:34:37 PM UTC+2, Tracy Miranda wrote:
> >
> > Thanks Tyler, Daniel & Mark for the feedback so far. 
> >
> > I've updated the JEP based on this: 
> > https://github.com/jenkinsci/jep/pull/176
> >
> > Please review and let me know any further thoughts.
> >
> > Tracy
> >
> > On Mon, Aug 13, 2018 at 8:22 PM, R. Tyler Croy  > > wrote:
> >
> >>
> >> Following up on this thread, Tracy's taken the initiative to create a 
> >> good JEP
> >> describing the proposed process here:
> >> https://github.com/jenkinsci/jep/pull/175
> >>
> >>
> >> As the primary poster of @jenkinsci, I'm really looking forward to 
> >> sharing some
> >> responsibilities with other passionate twitter/jenkins contributors :)
> >>
> >>
> >>
> >>
> >>
> >> -- 
> >> You received this message because you are 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/20180813192211.GG17800%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/2bb34025-53f4-4469-8d23-23799706bf80%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/20180817164214.GL17800%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Renaming Jenkins Essentials to 'Evergreen'

[R. Tyler Croy]

(replies inline)

On Wed, 15 Aug 2018, Jesse Glick wrote:

> On Tue, Aug 14, 2018 at 6:04 PM R. Tyler Croy  wrote:
> > The key aspect of it is _not_ the selection of
> > plugins, but rather how those plugins get out there to users.
> 
> That just means you are concealing one aspect behind another, since
> the only plugins which would be distributed using the ???evergreen???
> mechanism are those we consider, well, ???essential??? enough to track.
> Everything else comes from the update center (or is blocked outright).
> 
> While I certainly agree that having two names was confusing, I think
> the selection of plugins is a critical concern that should not be
> brushed aside as a detail. I recall KK discussing the notion of an
> Essentials team broadly trusted to work on (review, merge) anything in
> the transitive dependency closure of essential plugins (including core
> and component libraries), to reduce the friction of deploying coherent
> features via Evergreen, including tracking metrics, managing feature
> flags, and so on.


As I mentioned in the original email, the four pillars described in JEP-300 are
in tact, but the mere selection of some set of the plugins is not the marquee
feature here..

Any such notion from Kohsuke about a blessed team merging code in this
'brighter line' of functionality was never something defined in the original
scope of this effort:
<https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc>

The classic case of "GitHub configuration consolidation" is something I agree
should be solved, but a team of wizards refactoring and consolidating code is
only one potential solution to that problem.

There's still work scoped around the "Automatically sane defaults" pillar which
is more than likely going to address these user problems  with scripting,
configuration, or special functinality included in the Evergreen distribution


> Perhaps you just mean to disclaim responsibility for that effort, and
> someone else TBA is going to step in? Or are we really dropping the
> overall goals that were proposed for Essentials initially?

I am happy to disclaim the responsibility for a team in charge of maintaining
all sorts of plugins which I don't believe I ever signed up for :-P


Of course, this email thread is a notice about consolidation of a brand name
which users will see, not about potential long-term evolutions of the project 



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


signature.asc
Description: PGP signature

Renaming Jenkins Essentials to 'Evergreen'

[R. Tyler Croy]

I wanted to send an broader email to the dev list indicating that I will be
changing the name of what we have thus far referred to as "Jenkins Essentials"
to "Evergreen." The latter has been the name of the distribution system since
day one, and as we near completion on "Milestone 1", which will be useable by
actual people, I wanted to fix the name to ensure that what "it" is, is clear
and understandable.


Since the early days, "Essentials" has unfortunately been a bit of a confusing
name for some folks. It tended to be related to the "Suggested Plugins" feature
far more than I had ever wanted. The key aspect of it is _not_ the selection of
plugins, but rather how those plugins get out there to users.


>From my perspective, the always-automatically-up-to-date distribution aspect of
what we've built, *that* is the key take-away.


Evergreen captures that promise _far_ better in my opinion.

(with a nice hat-tip towards Green Balls and Blue Ocean's green status
indicator :))


The four pillars remain the same, but the key premise of Evergreen is being
highlighted much more with this change.


>From a practical standpoint, I will be submitting updates to the JEPs we have
written thus far, add an update note to old blog posts, and post an blog post
explaining what Jenkins Evergreen (nee Essentials) is and how to use it as of
Milestone 1 (:clap:).




Let me know if you've got any questions, and of course, I look forward to
chatting with many of you about Evergreen at DevOps World - Jenkins World San
Francisco coming up soon :D


Cheers
-R Tyler Croy

-- 
You received this message because you are subscribed to the Google 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/20180814220448.GI17800%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Bill of Materials

[R. Tyler Croy]

(replies inline)

On Tue, 07 Aug 2018, Oleg Nenashev wrote:

> Hi Tyler,
> 
> Thanks for the feedback!
> 
> 
> > I believe the only think which needs to be resolved which is likely just an
> > obsolete part of the example YAML.  The root `status` key in the YAML for a
> > "realized" BOM I don't believe we've ever actually used and is worth
> > removing.
> 
> 
> Actually I use it in some cases in order to implement custom packaging
> Pipelines after customWARPackager()
> .
> 
> 
>- BOM's specification lists explicit dependencies
>- BOM's specification does not require all dependencies to be explicit
>   - Some dependencies may have "dir" references
>   - Some dependencies may be transitive. JEP-309 permits that though
>   does not recommend for production use (dependency resolution
>   
> 
>   in the spec)
>   - "status" key returns the full list of resolved dependencies
>   - In addition to transitive deps, CWP uses "status" to squash the
>   "environment" definitions into a single list in order to show what was
>   actually packaged into the WAR file
> 
> I would rather prefer the "status" section to stay in the specification. It
> is helpful for CWP at least (though it may be possible to just generate a
> new output BOM). If we do that, it would be nice to get feedback from Raul
> who is also experimenting with processing of BOMs.
> 
> In order to address your comment, we could explicitly say that the "status"
> section is optional so that you do not need to implement it in Evergreen if
> not needed. WDYT?



I mentioned in a video call with Oleg this morning that I've gone ahead and
implemented the `status` section for the  Bill of Materials being used in the
jenkins-infra/evergreen repository.


Overall I'm quite happy with this work by Oleg and Carlos, and I will be
submitting a PR (with my BDFL-Delegate hat on) to mark JEP-309 as 'Accepted'
later today.


Thanks for the  hard work everybody!

-- 
You received this message because you are subscribed to the Google 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/20180814153826.GH17800%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Bill of Materials

[R. Tyler Croy]

(replies inline)

On Mon, 06 Aug 2018, Oleg Nenashev wrote:

> Hi all,
> 
> Status update: By now Custom War Packager has been released in 1.0, and 
> there are also many updates in Evergreen. IMHO it is a good time to get 
> this story over the fence.


Thanks for working to drive this to completion Oleg! Overall I think the
document looks great, and as of last Friday I had actually gotten the
implementation prepared for the Evergreen backend system (see:
https://github.com/jenkins-infra/evergreen/pull/169) which processes the
essentials.yaml and prepares the update records needed.


I believe the only think which needs to be resolved which is likely just an
obsolete part of the example YAML.  The root `status` key in the YAML for a
"realized" BOM I don't believe we've ever actually used and is worth removing.

I wanted to sanity check that with you first though.


If you remove that, I think overall this JEP looks good and is just about ready
to go.


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


signature.asc
Description: PGP signature

Re: Topic for Governance Meeting Tomorrow

[R. Tyler Croy]

(replies inline)

On Wed, 01 Aug 2018, Daniel Beck wrote:

> FWIW https://wiki.jenkins.io/display/JENKINS/Travel+Grant+Program is still 
> around, even though nobody has applied in the last few years. It doesn't go 
> up to 2000 USD though.


Weighing in with my crumbled board member hat on, I'm fully in favor of
utilizing the existing travel grant program for this. I am not in favor of
creating a greater one-off reimbursement without a properly structured and
agreed upon program in place.

Generally I support increased use of travel grants. I'm hopeful that some of
the "Jenkins Software Foundation" concepts we've been exploring with Linux
Foundation, as I highlighted in last year's Contributor Summit, will enable a
more sizable budget for travel grants in the future.



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


signature.asc
Description: PGP signature

Re: Upcoming JEP for usage of Incrementals repository

[R. Tyler Croy]

(replies inline)

On Thu, 17 May 2018, Baptiste Mathus wrote:

> Le mer. 16 mai 2018 à 13:14, James Nord  a écrit :
> 
> > So the objection I have is that as it stands in JEP-305 the versions are
> > releases and these are expected to be garbage collected.
> >
> > Anyone also wanting to consume incrementals via a proxy would need to
> > write tooling to garbage collect releases and there is also the Maven
> > principal that you never garbage collect releases, let alone the impact
> > this will have on other pipelines that do canary builds by picking up the
> > latest **release** of a artifacts/plugins in order to do bleeding edge
> > testing in our pipelines. And that is also discounting the ability once it
> > is in our mirror for things to accidentally depend on these releases.
> >
> I must confess I had missed reading related IEP-9 when reading JEP-305. I
> do agree releases should normally be kept basically forever.
> Now nowadays Nexus, for one, had added a dedicated Scheduled Task
> 
> to
> clean up also releases "Remove Releases From Repository" IIUC (I never used
> it myself, but did use a lot the other "Remove Snapshots From Repository").
> 
> So yes, this shows IMO a pretty usage of Maven, but it shows at least
> people using Nexus (and I suspect Artifactory can do the same) would
> normally *not* have to handle that themselves.
> 
> Now, about the whole artifact collection idea that I had missed:
> 
> * I think this part in IEP-9 could be just ditched overall, for now at
> least. As Jesse nicely phrases it below: "until storage costs start to
> raise eyebrows". IIUC what Daniel told me once, as it stands currently:
> anyway we never ever remove *any* artifacts from Artifactory, SNAPSHOTs are
> already kept forever. So I guess the eyebrow would have raised long ago if
> this was an issue. OK, this could grow possibly faster once Incrementals
> starts to get used more and more, we /might/ want to revisit then.
> ** (A possible way to revisit could for instance to better differentiate
> PRs from merged commits, and maybe more aggressively actually clean up
> artifacts coming from PRs).


There is no garbage collection currently implemneted with IEP-9.

There is simply no comparable usage today of our Artifactory environment in
terms of capacity planning. While we may not remove SNAPSHOTs today,
ci.jenkins.io isn't publishing those. And in fact, nothing compares to
publishing artifacts for every single pull request of every plugin (400+),
libraries (a few dozen), and core in ci.jenkins.io.

We're looking at many hundreds of megabytes of data per day uploading into
Artifactory, a hosted solution with somewhat unclear limtis (we basically will
fill it up until JFrog says "hey wtf m8"").


So basically, I'm not concerned with what "Maven best practices" prescribe, I
do not want the expectation to be that incremental built releases are going to
be kept indefinitely. Only so much disk space on the planet :)


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


signature.asc
Description: PGP signature

Re: Suggestion: versioning the schema for Configuration as Code

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


signature.asc
Description: PGP signature

Re: [Essentials] Error Telemetry Server API JEP Draft

[R. Tyler Croy]

(replies inline)

On Tue, 08 May 2018, Baptiste Mathus wrote:

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


Woohoo more designs! :)

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

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


Cheers

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


signature.asc
Description: PGP signature

Suggestion: versioning the schema for Configuration as Code

[R. Tyler Croy]

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

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

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



Thought I would share the idea.




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

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


signature.asc
Description: PGP signature

Re: Bill of Materials

[R. Tyler Croy]

(replies inline)

On Mon, 30 Apr 2018, Jesse Glick wrote:

> On Fri, Apr 27, 2018 at 12:54 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > why not just have the full artifact URL listed
> > in the Bill of Materials? For example:
> >
> >   plugins:
> > - groupId: org.jenkins-ci.plugins
> >   artifactId: git
> >   url: 
> > https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/git/3.8.1-rc1663.454c4a5e4d30/git-3.8.1-rc1663.454c4a5e4d30.hpi
> >
> > From the Jenkins Essentials perspective, all I really need is an artifact ID
> > and URL for the artifact, but I'm not sure if that's all that's needed for 
> > the
> > other use-cases here.
> 
> You could do that, though a plain `version` attribute would suffice,
> so long as the tool pulling binaries includes the Incrementals repo in
> its list of locations. _If_ you wish to permit branch references or
> local disk paths or other options in this format, then you would
> anyway need some alternative ways of referring to binaries.
> 
> The more interesting question to my mind is how you make edits to the
> manifest like the above. After you have more than a handful of plugins
> with versions like these, manually copying and pasting such
> URLs/versions would be cumbersome. I think JENKINS-50953 can be used
> to track this. For example, I might run something like
> 
> $ update-incrementals configuration/essentials.yaml
> 
> or
> 
> $ update-incrementals configuration/essentials.yaml git workflow-api
> 
> which for each selected component (or all) would check the current
> version; gather a list of all deployed versions (from
> `maven_metadata.xml`) that compare as strictly ???newer??? than that;
> filter those by commits which are ancestors of current `master`; pick
> the newest of the resulting versions; and edit the file to select that
> version.
> 
> You could then commit the result and push to a pull request, which
> would get validated by a PR builder somehow TBD, and if all automated
> checks pass it would be eligible for merging, meaning deployment to
> production.
> 
> WDYT? Admittedly the above is a very rough sketch, which I need to
> flesh out quite a bit.



If an update-incrementals tool existed, then yes, that would address my
concerns here. So long as something can automatically update my yaml file, i'm
happy to use it, I more wanted to make sure that we weren't going to have two
or three implementations of what `update-incrementals` effectively should be
providing.


-- 
You received this message because you are subscribed to the Google 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/20180430204749.GL2935%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Bill of Materials

[R. Tyler Croy]

(replies inline)

On Fri, 20 Apr 2018, Carlos Sanchez wrote:

> Hi there,
> 
> I have filed a new JEP to address the concept of Bill of Materials (BoM).
> 
> *https://github.com/jenkinsci/jep/pull/92
> <https://github.com/jenkinsci/jep/pull/92>*
> 
> The BoM idea came up after different conversations with Tyler/KK/Oleg and
> several more people - thanks for the feedback! - talking about how can we
> define a Jenkins package ("classic" jenkins, essentials, custom) to ensure
> that latest master of core and plugins can be easily used and tested, as
> well as the too typical use case of PRs in progress across multiple modules.
> 
> The main goal is to increase velocity by providing developers automatic
> artifacts and the result of tests against those artifacts before these
> combinations of PRs are merged. In order to create some safety nets that
> encourage contributions and facilitate reviews.


There have been a lot of comments on that pull request, but I wanted to bring
one aspect of the discussion back to the development mailing list.

As I have been working this past week with jglick on the incrementals
publishing, I'm recognizing that the yaml we sketched out previously requires
some logic to be re-implemented in a few different places.

Take the following snippet for example:

  plugins:
- groupId: org.jenkins-ci.plugins
  artifactId: git
  ref: PR-1663 # or how are pull requests handled here?


Whether it's the Jenkins Essentials tooling, custom-war-packager, or any
test/maven tooling, something is going to have to translate those GAV
coordinates into an actual artifact which is either downloaded, or locally
referenced.

In an incrementals build, a pull-request built Git plugin artifact would 
actually be
located:

https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/git/3.8.1-rc1663.454c4a5e4d30/git-3.8.1-rc1663.454c4a5e4d30.hpi

I'm not sure how I would build the tooling to use the above YAML to resolve to
the URL, which makes me wonder: why not just have the full artifact URL listed
in the Bill of Materials? For example:

  plugins:
- groupId: org.jenkins-ci.plugins
  artifactId: git
  url: 
https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/git/3.8.1-rc1663.454c4a5e4d30/git-3.8.1-rc1663.454c4a5e4d30.hpi


>From the Jenkins Essentials perspective, all I really need is an artifact ID
and URL for the artifact, but I'm not sure if that's all that's needed for the
other use-cases here.


Just thought I would raise the question since I don't feel like I understand
how to go from the Bill of Materials to binaries right now.



Cheers
-R Tyler Croy




-- 
You received this message because you are subscribed to the Google 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/20180427165458.GG2935%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Defining the client/server "update lifecycle"

[R. Tyler Croy]

A heads up on this thread, this work has become a Draft JEP:
https://github.com/jenkinsci/jep/tree/master/jep/307

Of particular note since I last updated this thread is the security section
which has come after a plethora of reading and reasoning on my part :)
https://github.com/jenkinsci/jep/tree/master/jep/307#security


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


signature.asc
Description: PGP signature

Re: External Artifact Storage

[R. Tyler Croy]

(replies inline)

On Fri, 13 Apr 2018, Carlos Sanchez wrote:

> PR submitted at https://github.com/jenkinsci/jep/pull/83


Related to this work is this pull request which implements extensions to
VirtualFile, which I would consider very key to this work:
https://github.com/jenkinsci/jenkins/pull/3302

With that pull request there have been some questions raised about how the JEP
Workflow interacts with the implementation workflow, and merging of code into
plugin and core repositories. I wanted to share the expectations I had in mind
when bringing over parts of PEP into JEP-1.

The workflow for a Standards JEP is generally going to be 
Draft->Accepted[0]->Final[1]

JEP-1 is somewhat intentionally vague on how these map to merges of pull
requests and APIs. My original thoughts around this were that this would be a
good thing and allow us the most flexibility in writing code alongside
discussing design and APIs, depending on the repository and design. I recognize
how this ambiguity also leaves room for confusion.


Working backwards, Final is the most clear and obvious in my opinion. A JEP
marked as Final means designs and APIs are merged, finalized, and considered
"supported" for whatever our hand-wavey-API-support-policy is (i.e. public
APIs) in whatever project they're being merged.

The requirements for implementation around Accepted[0] much more loosely
defined as:

"The proposed implementation, if applicable, must be solid, must not 
complicate
Jenkins unduly, and must be the same license as the component the proposal 
is
meant to added to"

In the case of Jenkins Essentials, we're merging code regardless of Accepted,
or even Draft JEP status, because obviously, that's most expedient given the
state of that project.

In the case of Jenkins plugins and core which are already being used, I
understand that is not the case. However, I think it would be a failure for JEP
if we are reluctant to merge code and make _use_ of it before the "Accepted" or
"Final" states are reached.

To a certain extent I believe that no API or design can be safely considered
Final without real world experimental or beta usage.  Hiding something behind a
feature flag, or a @Beta annotation, for core or plugins is (IMHO) a really
good thing to strive for even in the Draft stage to get _real_ usage of designs
in the hands of testers and users. All the while, still communicating our
intention that these are *beta* (not in the Google sense).

The quote "No plan survives contact with the enemy", and my favorite Mike Tyson
derivative "Everybody has a plan until they get punched in the mouth" come to
mind :)


With regards to the pull request for Jenkins core above, my recommendation for
the folks working on core is to merge and ship designed, documented, and
clearly marked Beta APIs which do not unduly complicate Jenkins, and of course
can be safely released and exercised in weekly and LTS releases. I think
plugins should be encouraged to follow similar guidelines at their
maintainers' discretion.


Optimizing for safely trying new things in released versions of code is IMHO a
very good thing.



Cheers



[0] https://github.com/jenkinsci/jep/tree/master/jep/1#accepted
[1] https://github.com/jenkinsci/jep/tree/master/jep/1#finalizing-a-jep

-- 
You received this message because you are subscribed to the Google 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/20180420163747.GF1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Defining the client/server "update lifecycle"

[R. Tyler Croy]

(replies inline)

On Wed, 18 Apr 2018, R. Tyler Croy wrote:

> 
> Howdy! I've been working this week to define the Jenkins Essentials
> client<->server contracts for handling the _actual_ updates of Jenkins
> Essentials.
> 
> To help me organize my thoughts, I sketched out a quick draft of a JEP
> yesterday afternoon which can be viewed here.
> 
> https://github.com/jenkinsci/jep/pull/89


After a very helpful review by Olivier, his comment embedded below, I had a
good hangout with Ba(p)tiste to determine a good way to handle the
"disconnected client" problem.

Olivier asked  (https://github.com/jenkinsci/jep/pull/89#discussion_r182350032)

Do you consider all updates as 'safe'?
What happened if a client didn't connect to the update service for month?
Is it an information that would be useful in the update manifest?


Baptiste and I discussed what the right way to handle this is, and some of the
thoughts I had swishing in the back of my brain bucket about utilizing "Update
Levels" rather than tailoring an Update Manifest for each instance
individually.

Consider two instances, Alpha and Bravo. They both are created at the same
time, at Update Level (UL) 1. Alpha stays online, and connected, for the next
14 days, while Bravo is disconnected until day 14.

Our state is now:

Alpha: UL14
Bravo: UL1


My first idea was to dry to have Bravo jump from UL1 -> UL14 but with Jenkins
Essentials' testing process, this would effectively be a completely untested
upgrade jump, and Baptiste and I considered it too risky.

Another idea we discussed was using a git-bisect(1) type approach, trying UL14,
if that fails, try UL7, and so on. We discarded this idea as well because it
would be completely untested.


What we ultimately decided was the right path forward was to use Update Levels
(contrary to what the JEP presently describes), and staggar the upgrade logic
for Bravo to where it can successfully go from UL1->UL2, then UL2->UL3, etc.

Baptiste also raised the point of "What if we know that Update Level 5 is a bad
update?" What we decided was that the backend services need the ability to mark
a specific Update Level as tainted. SO in this example, once Bravo arrived at
UL4, it would skip UL5, and upgrade to the untainted UL6.


There are definitely some user experience concerns with downloading updates and
restarting, but we decided that is something we're going to have to find a way
to communicate to an end-user ("Why does Jenkins keep restarting?") and set up
the update lifecycle to prefer stability and tested upgrade paths.



I will be updating the JEP with this discussion shortly, thanks for the
feedback thus far Olivier and Jesse!


If you're interested in joining the Jenkins Essentials open planning meetings,
we have our next on Monday April 23rd at 14:30 UTC 
(https://www.youtube.com/watch?v=SZK8fdGaVhk)



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


signature.asc
Description: PGP signature

[Essentials] Defining the client/server "update lifecycle"

[R. Tyler Croy]

Howdy! I've been working this week to define the Jenkins Essentials
client<->server contracts for handling the _actual_ updates of Jenkins
Essentials.

To help me organize my thoughts, I sketched out a quick draft of a JEP
yesterday afternoon which can be viewed here.

https://github.com/jenkinsci/jep/pull/89


Olivier already gave me some really helpful and thought provoking feedback, and
I would love to have a few more eyes on this client/server interaction as its
likely to be one of the most important interactions in the entire Jenkins
Essentials project.


One area which would be helpful, and I don't have a lot of thoughts invested in
yet, is that of "Update Manifest Authenticity". Fundamentally, we are
instructing the evergreen-client to download code for execution on an end-user
machine, and I want to be absolutely certain that the evergreen-client is
downloading the *right* code and not subject to man-in-the-middle attacks or
other forgeries leading to end-user compromise.

I discussed briefly in JEP-303 (Registration/Authentication) the notion of
Certificate Pinning in the evergreen-client
https://github.com/jenkinsci/jep/tree/master/jep/303#certificate-pinning
Which might be one potential solution here. Or we could model the existing
Update Center process where a certificate authority is baked into the client
and a custom server-side certificate signs the Update Manifest. Another idea
which comes to mind is the "traditional" gpg signing/verification which
yum/apt perform (Joe Damato has done some great presentations about how this
doesn't give you the trust you think it does if you search YouTube :)).

I'm open to suggestions on how we can effectively ensure Update Manifest
Authenticity, the easuer and safer the solution the better :)



Thanks for your time!


Toodles

-- 
You received this message because you are subscribed to the Google 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/20180418142050.GT1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

(replies inline)

On Tue, 17 Apr 2018, Oleg Nenashev wrote:

> Hi,
> 
> We are starting GSoC meetings next week. If you need somebody to dry-run 
> the SIG infrastructure, sign us up :)
> 
> Reasoning: Having recorded GSoC sessions would be definitely helpful so 
> that we can share meetings with students/mentors who miss meetings. OTOH I 
> am not sure whether this content is useful for other community members.
> 
> Actually I would propose to have 2 SIGs:
> 
>- GSoC - special for GSoC. All infrastructure is ready
>- Newcomer onboarding - Another SIG for newcomers in Jenkins community + 
>Q + discussions about contributor experience
>   - We could split generic GSoC meetings to there (e.g. plugin 
>   development intros & Co)


I'll add you as a manager to the Brand Account so you can use Hangouts on Air
for the GSoC discussions. I agreed that a GSoC Special Interest Group makes
sense, I don't think a "Newcomer" one does because I don't understand what the
"regular business" of the SIG would be. For example, it's very clear to me
what the purpose and mission of a GSoC SIG would be, and why they would meet
regularly.

I don't think we need to carve up everything we do into SIGs for the record, I
think there's a need for SIGs on specified "business" which requires a group's
regular attention, but that doesn't mean everything fits into the model IMHO.


If I'm misunderstanding or missing something about the mission for a
prospective Newcomer SIG, let me know.



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


signature.asc
Description: PGP signature

Re: Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

(replies inline)

On Wed, 11 Apr 2018, Ewelina Wilkosz wrote:

> I must say I only briefly scanned the part with all the jenkinsci-foo and 
> sig-foo :( it seemed like a lot indeed. I like the rest of the document 
> though! but this part was almost verwhelming... 
> that's why I asked about SIG Lead responsibility. If we want to do a good 
> job we should make it as easy as possible - not that I'm lazy, but let's be 
> realistic 
> 
> We can see people being confused about Jenkins Developers and Jenkins Users 
> mailing list - if we have too many groups to choose from I would probably 
> spend so much time trying to figure out which one is the one I should post 
> in


Thanks Ewelina and Ba(p)tiste, I've made some changes and removed the manymany
recommended mailing lists as I don't think we're at the point of needing them
yet.


Filed as a proper Draft now: https://github.com/jenkinsci/jep/pull/81

-- 
You received this message because you are subscribed to the Google 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/20180416141708.GH1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Upcoming JEP for usage of Incrementals repository

[R. Tyler Croy]

(replies inline)

On Fri, 13 Apr 2018, Jesse Glick wrote:

> Filed a draft request:
> 
> https://github.com/jenkinsci/jep/pull/84


Jesse this is a very thorough and well-thought out document! Thank you so much
for putting the effort into it.

I understand that you have prototyped this work with strictly plugins at this
point, and the document makes allusions to core and 'modules' potentially being
able to use this same approach and tooling.

The only question I had was whether you think it's important to verify that
core and modules function with this model before rolling out this type of a
design? From the IEP-9 standpoint, I don't really care what tooling is required
to get  incremental builds into the maven repository, but I'm not sure if you
consider applicability to core part of "acceptance criteria" for this design.

I hope the question makes sense, put more shortly: does core need to be figured
out for this to come into effect?




Have a good weekend :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/20180414002112.GE1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins External Artifact Storage core changes in LTS

[R. Tyler Croy]

(replies inline)

On Fri, 13 Apr 2018, Oliver Gond??a wrote:

> On 2018-04-13 18:23, Carlos Sanchez wrote:
> > Hi Oliver,
> > 
> > There are some changes for core that would be really helpful to have in
> > hands of people for testing sooner than later
> > 
> > https://github.com/jenkinsci/jenkins/pull/3302
> > 
> > All new methods are marked with the new @Beta annotation so it should be
> > clear that it's not final.
> > 
> > We expect this to be in the next weekly or so,but I would really like to
> > ensure we can pull this into the next LTS if at all possible,what can I
> > do to help prepare these changes for the LTS,even if we tried to
> > backport it?
> 
> Hi, Let's make the discussion public.
> 
> My personal take is the LTS and Beta.class are quite orthogonal in
> principle. When it comes to the actual change, it feels far from trivial for
> such an exception IMO. What is the motivation here? Backporting this will
> get it in LTS in 4 weeks, otherwise it will get in in 8 weeks.
> 
> Thoughts? I would really like to avoid backporting something before it has
> its final shape (IOW, merged to master).


Hey Oliver, I was chatting with Carlos about this earlier and encouraged him to
reach out to you to better understand your thoughts for considering code coming
into the LTS.

>From my understanding of what Carlos is asking about, is not pulling anything
into an LTS which isn't already in a Weekly release. Rather, I think Carlos is
apprehensive about the timing between Weekly releases and LTS, and is worried
about missing the last Weekly before our typical 2-weeks-before LTS cutoff."

I think Carlos's team has worked quite hard to get the underlying code to
enable external artifacts ready, and considers one indication of "success" to
have that code delivered in our next LTS cycle, since LTSes are consumed by the
vast majority of Jenkins users who would benefit from this functionality.


I *hope* I've captured the situation clearly.


The questions Carlos has about LTS timing I think are all moot assuming that
the aforementioned pull request gets reviewed and merged in a timely manner for
next week's release (from my understanding).



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


signature.asc
Description: PGP signature

Heads up! Jenkins is on YouTube, with more videos coming soon!

[R. Tyler Croy]

The Jenkins project has been on YouTube for a while, but I recently
transitioned our channel to a "Brand Account", which means we can share
permissions to post videos _much_ more easily:

https://www.youtube.com/c/jenkinscicd


I am hoping that we can share access, not only for the Jenkins Online Meetups
(https://www.meetup.com/Jenkins-online-meetup/), but also for more project
meetings and group meetings (see also:
https://groups.google.com/d/msg/jenkinsci-dev/6-1mZoKp4hM/EHz5NaPRBgAJ).


Hope you all find more video content helpful!


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


signature.asc
Description: PGP signature

Re: Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

(replies inline)

On Thu, 22 Mar 2018, R. Tyler Croy wrote:

> 
> I have been looking at some of the great things the Kubernetes community has
> been doing for ideas we can borrow, and one idea which really sticks out is:
> Special Interest Groups (SIGs)
> <https://github.com/kubernetes/community/blob/master/governance.md#sigs>
> 
> A full list of the Kubernetes community SIGs can be found here:
> <https://github.com/kubernetes/community/blob/master/sig-list.md>
> 
> I think we already have some groups, which are almost informal SIGs, such as
> Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> formalize, and support from a community infra standpoint are:


Here's an update, I've written out my first draft of what SIGs might look like
for us here: https://github.com/jenkinsci/jep/pull/81

Please let me know what you all think, I'm especially curious for Daniel,
Oliver, Ewelina, and Carlos's thoughts as I am hoping this helps you all get
more contribution and focus :)



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


signature.asc
Description: PGP signature

Re: [Essentials] Instance Health Checking JEP: ready for first review

[R. Tyler Croy]

(replies inline)

On Tue, 10 Apr 2018, Jesse Glick wrote:

> I for one would find it easier to comment on a PR, but IIRC JEP
> editors have discouraged this for some reason
> 
> 
> ???Healthness??? is not a word???it is just ???health???.
> 
> 
> I would suggest `/metrics/evergreen/healthcheck` just return an empty
> JSON document, or a simple ???OK??? marker by default???only listing things
> that are _not_ healthy.

It was my understanding that this format was simply the Dropwizard healthcheck
format.

Do you have some reasoning for this you could share? Otherwise this seems like
a bit of personal preference to me, but I'm sure there's some logic I could be
missing 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/20180410143346.discdbodxgiudmfz%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

Just a heads up to any of those interested, the pull requests implemneting this
functionality, described in JEP-303
(https://github.com/jenkinsci/jep/tree/master/jep/303)
can be found here:

 * Registration component: https://github.com/jenkins-infra/evergreen/pull/37
 * Login component: https://github.com/jenkins-infra/evergreen/pull/42


Since Kohsuke has added me as the BDFL delegate for this JEP, once the
appropriate review has finished, I expect to mark JEP-303 as 'Accepted' by
mid-next week.


Thanks for all your feedback and help on this one!


Cheers
- R Tyler Croy

-- 
You received this message because you are subscribed to the Google 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/20180406134745.wilgpn4vezjpaxl6%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: HEADSUP: Breaking change for Docker Pipelines coming on ci.jenkins.io

[R. Tyler Croy]

(replies inline)

On Mon, 02 Apr 2018, R. Tyler Croy wrote:

> 
> I have put this off as long as I feel prudent, but later this week I will be
> upgrading the Docker Pipeline plugin on ci.jenkins.io from 1.14 to 1.15.1 
> which
> will break Docker Pipelines which rely on the implicit ENTRYPOINT override
> behavior which was supposed in 1.14, but removed for 1.15.1
> (https://issues.jenkins-ci.org/browse/JENKINS-41316).


And now, the gripping conclusion to this thread. The ugprade has been
deployed.



-- 
You received this message because you are subscribed to the Google 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/20180405140143.ygy4qxyy3jq4tnva%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [DISCUSS] Change Jenkins default logging format

[R. Tyler Croy]

(replies inline)

On Wed, 04 Apr 2018, Oleg Nenashev wrote:

> Hi Baptiste,
> 
> Anyone can easily change the logging format in Jenkins by passing custom 
> J.U.L properties file.
> So it should not be a problem to change logging format even if you do not 
> add a custom logging appender for ELK.
> 
> Changing a default logging format may cause regressions in existing 
> monitoring systems. I would rather be conservative and keep the default 
> logging format in Jenkins unless there is a strong justification to do 
> that. New subprojects like Jenkins Essentials and Jenkins X could easily 
> change the default format, because they have no compatibility commitment so 
> far.


Thanks for sharing your thoughts Oleg, it makes me wonder: how could we
quantify the positive/negative impact of this (arguably) "bad default."

I'm reminded of some of the pre-Jenkins 2 discussions about security defaults
for example. I spent some time trying to discover Jenkins-log-parsing projects,
tools, and their communities to which we could reach out. Unfortunately I
wasn't able to find anything big past a couple of blog posts :-/

>From my personal experience as an Operator, compact and easily parseable
(sed/awk/perl) one-line logs are HUGELY valuable and worth any temporary
heartburn some people may experience with their existing hacks.



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/20180404172432.wlr4c5f35tuvnijj%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: HEADSUP: Breaking change for Docker Pipelines coming on ci.jenkins.io

[R. Tyler Croy]

(replies inline)

On Mon, 02 Apr 2018, Jesse Glick wrote:

> On Mon, Apr 2, 2018 at 9:52 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > If you have a Jenkinsfile in ci.jenkins.io that relies on
> > docker.image().inside() or the equivalent in Declarative Pipeline, that
> > Pipeline may *break*
> 
> These ought to be pretty easy to find for an admin on this server???scan
> the log¹ of the last build of every job named `master`, if it were
> ???successful??? (i.e., incl. `UNSTABLE`), looking for the
> `withDockerContainer` step. Could you just trigger fresh builds of all
> these jobs after the upgrade and notify the owner if the build fails?


This is not a "pretty easy" task as far as I am concerned. Without tooling for
grep + Script Console abuse for triggering this, I won't be spending any time
on this. There are literally hundreds of other INFRA tasks I would rather
dedicate time to :-/

If Pipelines break, then that's unfortunate and thus this notice. We are not
going to fall behind on further upgrades to Docker Pipeline due to this change
in behavior by the plugin.

I've already expressed my severe displeasure regarding the change which causes
this breaking behavior, but do not plan to spend any time sugar-coating this
for ci.jenkins.io usage.

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/20180402171312.sknppgpczrckq24o%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

HEADSUP: Breaking change for Docker Pipelines coming on ci.jenkins.io

[R. Tyler Croy]

I have put this off as long as I feel prudent, but later this week I will be
upgrading the Docker Pipeline plugin on ci.jenkins.io from 1.14 to 1.15.1 which
will break Docker Pipelines which rely on the implicit ENTRYPOINT override
behavior which was supposed in 1.14, but removed for 1.15.1
(https://issues.jenkins-ci.org/browse/JENKINS-41316).

I know at least the jenkinsci/docker Pipeline will break due with invocations
such as this one:
https://github.com/jenkinsci/docker/blob/master/Jenkinsfile#L21
See also:
https://github.com/koalaman/shellcheck/blob/master/Dockerfile#L36


>From my understanding, the remediation for this upgrade/regression (depending
on your perspective) is to execute:

docker.image('foo').inside('--entrypoint= ') {
sh 'blah'
}


It is not easily knowable what the size and impact of this change is going to
be, so I'm sending this heads up out.

If you have a Jenkinsfile in ci.jenkins.io that relies on
docker.image().inside() or the equivalent in Declarative Pipeline, that
Pipeline may *break* starting on Thursday, April 5th.



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/20180402135200.v2ek6zwq76ld4enb%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

My colleague in CloudBees Operations, Ben Walding, shared some feedback with me
off list, which he's allowed me to share more broadly. A summary of his
questions are below with some of my responses inline

* UUID: If the UUID is the fingerprint of the Jenkins instance, are there any
  PII issues?


In this design the UUID is literally a UUID generated on the server
side by the Node `uuid` module, so it's only correlated to the
instance after the registration has completed. That said, yes there is
a GDPR identification concern if/when that Instance UUID is associated in a
backend database with an individual's identity (e.g. GitHub Username). At this
point this is a concern which I am aware of, but we're not far enough along in
Jenkins Essentials to where this affects our designs.


* Service Authentication: I'm assuming you're thinking of TLS/HTTPS for
  transport protection between the client and the server?


TLS is definitely a requirement full stop. I have updated the document with
this under the Security section.


* JWT Bearer Tokens vs. Request Signing:  IIUC, the JWT is used as part of an
  HMAC signing of the request?  The way you've talked about it, it seems more
  like a Bearer token (which have risks around replay).


JWT is being used much more as a bearer token rather than HMAC
signing of the request. ("JWT Simple" :))

At this point I do not see additional value in request signing, for the
additional key management overhead to pass a client's public key around between
backend services in order to verify request signatures. I've added some
additional notes to the "Alternative Approaches" section of the document to
capture this concern however.




I've had some constructive discussions around this design, and have made
substantial progress on the implementation work, so I have proposed my JEP
document for numbering and Draft status in this pull request:
https://github.com/jenkinsci/jep/pull/74




Thanks for providing feedback everybody!


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/20180330135604.fn6c7qr4n733djc6%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Tue, 27 Mar 2018, Baptiste Mathus wrote:

> (Adding in CC Emmanuel Lécharny <http://people.apache.org/~elecharny/>, who
> took a look at the proposal)
> 
> Trying to summarize our chat on Twitter, I see two outstanding points:
> 
> * Emmanuel is rightly questioning/concerned about the potential of DDoS for
> this JEP.
> Tyler, should we add something about this in the JEP, or do you consider it
> more something to be addressed in an IEP on the infra side?
> (also, downstream to it AIUI, the Telemetry and other services are all DDoS
> vectors)


I consider the discussion about rate limiting (for example) to be the future of
the deployment aspect of these services as well, but guess who will be writing
the IEP! :)

Concerns about a DDoS as they might apply to the client/service interaction are
definitely worth discussing in relation to the JEP. However, based on what I
interpret is Emmanuel's feedback, it's not the interactions necessarily but
rather a "good infra hygiene" concern which I understand.



> * "MITM for expiry": it seems possible to reuse an UUID signed with the PK.
> "Ideally, to renew the token, you should have a 'nonce' to avoid MITM"



This feedback I'm not sure I understand. The UUID and public key are only ever
exchanged on initial registration, and then the signed payload (indicating
authenticity) is use for the "login" behavior. On JWT expiry, the login flow is
re-initiated rather than the registration flow, so I'm not sure I understand
where the Man-in-the-Middle for expiry concern would come in.

Perhaps something is getting lost in translation here on my end?




Thanks for acting as a proxy Baptiste, and thanks Emmanuel for taking the time
to look at the proposal!


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/20180327155642.vmnah5lpxnhuxxx2%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Mon, 26 Mar 2018, Jesse Glick wrote:

> Jenkins already includes the `instance-identity` module, which is the
> standard mechanism¹ for both uniquely identifying a Jenkins
> installation, and permitting asymmetrically-encrypted communications
> with it. Is there a reason you are not using it? If so, that should be
> clearly documented under ???Alternative Approaches???. There is a vague
> mention of OpenSSH keys, but this module is not limited to SSH (much
> less OpenSSH), and public-key encryption has widespread library
> support.


Thanks for taking a look Jesse! You're right that Jenkins already does have an
instance identity floating around. In a much earlier iteration of my thinking I 
was
considering using this until I started to think about how this would work in
practice for new installations.

Unfortunately when the jenkins/evergreen image comes online and checks for
updates, it will not have run `jenkins.war` at all yet, and therefore no
instance identity. Rather than have one unprotected/identified route in the
service backend for bootstrapping new nodes, I am erring on the side of
treating all "got updates?" requests the same, which requires a client
registration and identity to kick the process off.

You're absolutely right that the 'Alternative Approaches" section doesn't list
this and should, I'll update shortly.



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/20180326153407.5on7xn7gdl7odfue%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

(replies inline)

On Mon, 26 Mar 2018, Daniel Beck wrote:

> 
> > On 22. Mar 2018, at 22:04, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > 
> > I think we already have some groups, which are almost informal SIGs, such as
> > Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> > formalize, and support from a community infra standpoint are:
> > 
> >* Clear problem domain/focus area.
> > ???
> > 
> > Some SIGs which I would love to see for starters, would be:
> > 
> > * Security, lead by Daniel
> 
> What's the intended relation between existing teams and SIGs?
> 
> I'm asking mostly about security, which is more narrow in scope that what a 
> potential 'security SIG' would be.
> 
> Would there be a security team with the narrow scope, and a security SIG with 
> much wider scope?


I'm curious why you assume that the security SIG would be broader in scope than
the present day CERT?

Based on the Kubernetes project's descriptions of SIGs, I think cERT is more or
less a SIG already :P



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/20180326151341.gywu5lmjltsxcadf%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[Essentials] RFC: first cut at registration and authentication for Jenkins Essentials

[R. Tyler Croy]

I've been hammering my head against the problem of registering and
authenticating Jenkins Essentials instances all week (and boy does my head
hurt!) but now, after 6pm on Friday evening, do I feel like I have a
design/concept worth soliciting feedback on.

Since there's so much context and detail necessary, I went ahead and wrote the
majority of the JEP document here:
https://github.com/rtyler/jep/tree/essentials-registration/jep/


I'm not sure how familiar this topic area is to many Jenkins contributors, so
I'm also asking for feedback off-list from colleagues of mine from previous
jobs where we built similar systems with similar requirements. If you have
similarly skilled colleagues or security professionals you work with, I would
appreciate you asking for their thoughts if they have the time as well.


The local prototype code I have for this is so gnarly and embarrassing that I'm
not going to show you all just yet :) But suffice it to say, the approach
generally works, just needs more tests ;)



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/20180324020555.p26pfpln3j722m5r%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

(replies inline)

On Wed, 21 Mar 2018, R. Tyler Croy wrote:

> Just a heads up in case anybody on this thread is interested, I've put a
> hangout on the Jenkins project calendar to discuss this topic further on
> Friday:
> 
> <https://calendar.google.com/calendar/event?eid=MGoyYm5nbXJsNDAyNWtlMGgxNmoxYzdxanEgNHNzMTJmMG1xcjN0YnAxdDJmZTM2OXNsZjRAZw=GMT-07:00>


Thanks Vivek, Andrew, Daniel, Sam, Jesse, and Baptiste for joining! Our
collected meeting notes have been archived here:

https://github.com/jenkins-infra/evergreen/tree/master/docs/meetings/2018-03-23-JENKINS-49852-pipeline-usage-telemetry


As per our discussion, I've filed the following ticket to at least define how
metrics will be collected in the context of a Jenkins Essentials distribution:
https://issues.jenkins-ci.org/browse/JENKINS-50373


Follow-up work will entail creating a prototype or two hooking up the Metrics
plugin together with Pipeline's GraphListener. Once that approach is validated,
I think we'll be able to move a broader discussion forward for Pipeline
instrumentation which can benefit both the development of Jenkins Essentials
but also Pipeline itself.


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/20180323162720.26cb5idxz6hv3at6%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

(replies inline)

On Thu, 22 Mar 2018, Jesse Glick wrote:

> On Thu, Mar 22, 2018 at 5:04 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > Regularly scheduled and published meetings. I can easily imagine re-using
> > #jenkins-meeting or our public YouTube channel for regularly scheduling
> > and hosting weekly meetings for these various groups.
> 
> gitter.im feels more accessible than IRC, and automatically archived.


Gitter is logged, but that's a far cry from the meeting notes which we're able
to automatically generate and archive on http://meetings.jenkins-ci.org/ :-/

I haven't found a preponderance of good "gitter" bots out there on the
internets yet.


That said, in the context of the SIGs proposal, I don't have a strong opinion
on where people have meetings, so long as they're published on a calendar ahead
of time, are open, and are recorded in some form or fashion.


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/20180322213052.3rmffo72bki6zhot%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Request for comments: Special Interest Groups (SIGs) for the Jenkins project

[R. Tyler Croy]

I have been looking at some of the great things the Kubernetes community has
been doing for ideas we can borrow, and one idea which really sticks out is:
Special Interest Groups (SIGs)
<https://github.com/kubernetes/community/blob/master/governance.md#sigs>

A full list of the Kubernetes community SIGs can be found here:
<https://github.com/kubernetes/community/blob/master/sig-list.md>

I think we already have some groups, which are almost informal SIGs, such as
Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
formalize, and support from a community infra standpoint are:

* Clear problem domain/focus area.
* Regularly scheduled and published meetings. I can easily imagine re-using
  #jenkins-meeting or our public YouTube channel for regularly scheduling
  and hosting weekly meetings for these various groups. I run a weekly
  infra team sync on jenkins.io/hangout for example, but that's not
  recorded anywhere :(
* "Chairs" (i.e. team leads)
* Dedicated discussion channel/group (i.e. mailing list)


Some SIGs which I would love to see for starters, would be:

 * Security, lead by Daniel
 * GSoC, lead by Oleg
 * Infra, lead by Olivier and myself
 * Cloud Native (Kubernetes, Jenkins X, CLOUD, etc), lead by Carlos
 * Essentials, lead by myself
 * LTS, lead by Oliver
 * Automation/Configuration (config as code, puppet, chef, etc), lead by Ewelina


>From my part on the infrastructure side, I'm more than willing to do the
necessary work to support SIGs, as I really feel like they will help bring more
folks to the table for focused contribution to the Jenkins project.


I'm curious how others feel about a SIG structure and whether you all agree
that it will help channel/focus discussions and contributions?



If there's strong interest, I'm happy to take point on writing a Process JEP.


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/20180322210421.4ikcudf7m65yilvo%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: GSOC - Office Hours 3-23-18

[R. Tyler Croy]

(replies inline)

On Wed, 21 Mar 2018, Oleg Nenashev wrote:

> Hi Tyler,
> 
> I will update the website in few hours.
> I also plan to setup other last-chance timeslots, so I will make changes in
> a bulk mode.

I am also going to guess that Steve did not mean 8am UTC, which I believe is
11pm in his/our timezone :)



- 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/20180321215929.naohfz5sdvcsklwm%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome

[R. Tyler Croy]

(replies inline)

On Wed, 21 Mar 2018, Baptiste Mathus wrote:

> FYI JEP now officially filed for review at
> https://github.com/jenkinsci/jep/pull/67


A friendly reminder from one of the JEP Editors, please keep the discussion on
this mailing list thread about the document.

At this stage of the game the only changes/edits on the pull request will
likely be copy edits rather than structure edits. By the end of the day I will
likely give this a number, and merge this as a `Draft` into repository, so this
PR is not a great place for design discussion :)

use the list, luke.



> 
> Thank you everyone!
> 
> 2018-03-20 23:21 GMT+01:00 Baptiste Mathus <m...@batmat.net>:
> 
> > Hello everyone,
> >
> > Sorry for the time it took to get back here. I think I finally addressed
> > all comments.
> >
> > https://github.com/batmat/jep/pull/1 is ready for another round of
> > comments.
> >
> > I hope that no big thing surfaces again, though obviously there will be
> > issues discovered later, but I feel like we have been thinking about it
> > enough to be able to move forward.
> >
> > Thanks a lot.
> >
> > 2018-03-16 16:10 GMT+01:00 Jesse Glick <jgl...@cloudbees.com>:
> >
> >> On Wed, Mar 14, 2018 at 1:55 PM, R. Tyler Croy <ty...@monkeypox.org>
> >> wrote:
> >> > core and plugin upgrades can result in
> >> > modification of config.xml and other object-serialized-files on disk
> >> when an
> >> > upgrade occurs.
> >>
> >> Does happen, but rarely. In most cases, format changes take effect on
> >> disk only when a `Saveable` object is in fact saved for some other
> >> reason???a *Save* button in the UI, for example.
> >>
> >> > This means an upgrade of Jenkins Essentials has a very real potential
> >> to cause
> >> > irreversible modifications to files on disk which prevent a safe
> >> rollback.
> >>
> >> This is true.
> >>
> >> > "bricking" a Jenkins Essentials instance is a severe failure for the
> >> project
> >>
> >> This is what needs to be defined much more carefully. What would cause
> >> an installation to be ???bricked???, exactly? Years of work by core devs
> >> (see JIRA issues with label `robustness`) have solved most cases where
> >> Jenkins would fail to start or be used in a basic capacity merely due
> >> to unreadable configuration files. You might get *Discard Old Data*
> >> warnings, of course, but these are not fatal.
> >>
> >> > we need to prevent against irreversible modifications to files causing
> >> > runtime failures
> >>
> >> That is a much broader requirement, at least if ???runtime failures???
> >> could be interpreted as things like ???the deployment stage in all my
> >> pipelines started failing???, and it is not clear to me that the
> >> proposal as it stands comes close to satisfying 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/ms
> >> gid/jenkinsci-dev/CANfRfr2-jQ7HgKteHX%3DvyqPrCEHATD-q2QJwqE8
> >> ggJOYM%3D6Bcg%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/CANWgJS5mWyWAhktJW%3DiiQqfHGe8PYYnggz1p7KTZF7%3DjB7Q4dA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

- 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/20180321143705.se4hb3q6tbdtdlyw%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

Just a heads up in case anybody on this thread is interested, I've put a
hangout on the Jenkins project calendar to discuss this topic further on
Friday:

<https://calendar.google.com/calendar/event?eid=MGoyYm5nbXJsNDAyNWtlMGgxNmoxYzdxanEgNHNzMTJmMG1xcjN0YnAxdDJmZTM2OXNsZjRAZw=GMT-07:00>


- 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/20180321144945.iy3m7aw4ibwh74u7%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

  Usually that shouldn't be a huge issue unless the Groovy is 
> complex.  
> 
> If that's too noisy there might be ways to insert Listeners for the Step 
> itself (more complex though) -- I think using the FlowNodes is good enough 
> for now and gives us a solid first-order approximation that is useful 99% 
> of the time. 
> 
> I would also like to extend this by breaking it down into separate metrics 
> per step type, i.e. runtime for sh, runtime for echo, for 'node', etc.  
>  This is easier than you'd think since you can fetch the StepDescriptor and 
> call getFunctionName to get a unique metric key for the step.   This is far 
> more useful to us than just average step timings, because it helps spot 
> performance regressions in the field. 
> 
> Other aggregates of interest: total time spent in each step type for the 
> pipeline and counts of the FlowNode by step per pipeline.  This will show 
> if we're spending (for example) a LOT of time running 
> readFile/writeFile/dir steps due to some sudden bottleneck in the remoting 
> interaction and also reveal which step types are used most often.   Knowing 
> which steps are used heavily helps me know which deserve extra priority for 
> bugfixes, features, and optimizations.
> 
> It actually *sounds* far more complicated than it really is -- this would 
> be a pretty trivial afternoon project I think. 
> 
> > Runtime duration per Pipeline
> 
> I already have an implementation.  Same plugin as above.  It's exposed as a 
> DropWizard histogram as well, so you get rates + aggregate times with 
> median, mean, etc. 
> 
> *Other desired metrics:  *I think we want FlowNodes created as a rate per 
> unit time (I have an implementation in the same plugin above).   I also 
> have an impl for this already (same plugins as before). 
> 
> If we could find a way I'd really like to have a counter of how many 
> elements of GroovyCPS logic are run and how many function calls (for 
> off-master you obviously wouldn't get this data).  This is something useful 
> for measuring the real complexity of their Groovy -- even better than 
> Liam's Cyclomatic Complexity metric because it directly tracks runtime 
> operations, not just code structure.   I have notions how we'd accomplish 
> this.
> 
> On Friday, March 16, 2018 at 6:55:58 PM UTC-4, Andrew Bayer wrote:
> >
> > It???s a normal step - what I???m talking about is counting Pipelines 
> > containing one or more script blocks, I.e., what percentage of total 
> > Declarative Pipelines use script blocks, which I think is a more useful 
> > metric than just how many script block invocations there are.
> >
> > A.
> >
> > On Fri, Mar 16, 2018 at 5:32 PM R. Tyler Croy <ty...@monkeypox.org 
> > > wrote:
> >
> >> (replies inline)
> >>
> >> On Fri, 16 Mar 2018, Andrew Bayer wrote:
> >>
> >> > If we???re going to be tracking step invocations anyway, it???d be 
> >> interesting
> >> > to count the number of Declarative Pipelines with a script block, maybe?
> >>
> >> I kind of assumed that if we were incrementing a counter on step 
> >> invocations
> >> that script{} would be collected already by the machinery, e.g. isn't it 
> >> "just"
> >> a step?
> >>
> >> If it's a special snowflake then I'll make sure to include it in my 
> >> design.
> >>
> >>
> >> A few more which come to mind now that I'm thinking about Script:
> >>
> >>  * Count of stages per Pipeline
> >>  * Count of Pipelines with the Groovy sandbox disable
> >>  * Time spent in script{} block
> >>
> >>
> >> Thanks for the ideas abayer!
> >>
> >>
> >> 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-de...@googlegroups.com .
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/jenkinsci-dev/20180316213201.ckenekkqcbgtsuzx%40blackberry.coupleofllamas.com
> >> .
&g

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

(replies inline)

On Fri, 16 Mar 2018, Andrew Bayer wrote:

> If we???re going to be tracking step invocations anyway, it???d be interesting
> to count the number of Declarative Pipelines with a script block, maybe?

I kind of assumed that if we were incrementing a counter on step invocations
that script{} would be collected already by the machinery, e.g. isn't it "just"
a step?

If it's a special snowflake then I'll make sure to include it in my design.


A few more which come to mind now that I'm thinking about Script:

 * Count of stages per Pipeline
 * Count of Pipelines with the Groovy sandbox disable
 * Time spent in script{} block


Thanks for the ideas abayer!


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/20180316213201.ckenekkqcbgtsuzx%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

(replies inline)

On Fri, 16 Mar 2018, Daniel Beck wrote:

> 
> > On 16. Mar 2018, at 21:28, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > 
> > * What are other metrics which would positively impact the development of
> >   Jenkins?
> 
> Assuming the Essentials setup allows for whitelisting pipeline methods, 
> knowing which methods are whitelisted (or got rejected on whitelisting 
> attempt) would be useful to guide improvements of the default whitelist and 
> the blacklist.
> 
> Basically, INFRA-1285, which I haven't had time to work on.


Good suggestion! I'll incorporate that into my design document.


- 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/20180316212801.rzjh7tpe4gftp4ta%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[Essentials] Collecting usage telemetry from Jenkins Pipeline

[R. Tyler Croy]

The successful adoption and iterative improvement of Jenkins Essentials [0] is
heavily contingent on a spectrum of automated feedback which I've been
referring to as "telemetry" in many of the design documents. I wanted to start
discussing the prospect of collecting anonymized Pipeline usage telemetry to
help Jenkins Essentials, Blue Ocean, and Pipeline teams understand how users
are actually using Jenkins Pipeline.

James Dumay has already prototyped some similar work[1] for collecting
behavioral telemetry in Blue Ocean, but what I'm proposing would be much more
broad in scope[2]. The metrics I am interested in, to help us understand how
Pipeline is being used, are:

 * Counts:
   * configured Declarative Pipelines
   * configured Script Pipelines
   * Pipeline executions
   * distinct built-in step invocations (i.e. not counting Global Variable 
invocations)
   * Global Shared Pipelines configured
   * Folder-level Shared Pipelines configured
   * Agents used per-Pipeline
   * Post-directive breakdown (stable,unstable,changed,etc)

 * Timers
   * Runtime duration per step invocation
   * Runtime duration per Pipeline


I believe this is a sufficiently useful set of metrics to send along, but the
two questions I could use help answering are:

 * What are other metrics which would positively impact the development of
   Jenkins?
 * Are there concerns about implementation feasibility for any of these?


I am planning on using statsd (sent to the project's Datadog account), so
sampling and controlling the volume of individual metrics is not something I'm
terribly worried about.



Happy to hear any feedback y'all are willing to share!


[0] https://github.com/jenkins-infra/evergreen#evergreen
[1] https://github.com/jenkinsci/blueocean-plugin/pull/1653
[2] https://issues.jenkins-ci.org/browse/JENKINS-49852



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/20180316202818.hgl5irxnuqduq24v%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [Essentials] Using non default locations for builds and workspaces (was: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome)

[R. Tyler Croy]

(replies inline)

On Thu, 15 Mar 2018, Baptiste Mathus wrote:

> I thought I'd start a dedicated email here about that part after some
> feedback I got in https://github.com/batmat/jep/pull/1.
> I know people are very busy so maybe an email is easier for many than
> looking at the PR.


Thank you for bringing this discussion back to the jenkinsci-dev@ mailing list,
I think this will give more people to an opportunity to weigh in and
consolidate our discussions into threads for easy linking in the JEP
"References" section.

More below..

> So the one the ideas I have for Essentials' data snapshotting system is to
> use the configuration parameters to put builds and workspaces under a
> single and non default root
> <https://github.com/batmat/jep/blob/03d3404aba079b2f9b67284f6fc9940bf2ccfacd/jep/302/README.adoc#segregate-job-configuration-and-build-data>
> .
> 
> Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME*
> (instead of everything under *jobs* as it is usually):
> var/
> ? the_job
> ? builds
> ???   ? 1
> ???   ???   ? build.xml
> ???   ???   ? changelog.xml
> ???   ???   ? log
> ? workspace
> jobs/
> ? the_job
> ? config.xml
> 
> Jesse <https://github.com/batmat/jep/pull/1#discussion_r174508332> and James
> <https://github.com/batmat/jep/pull/1#discussion_r174472740> are even
> saying we should move the var directory somewhere else *not* under
> JENKINS_HOME.


I cannot say I have ever intentionally moved /jobs/ around in this manner, I
assume that it "just works" and there's no quality concerns we should have from
a non-standard placement of data on disk?

Otherwise I have no problems with this.


> Also, saying that we should not even (try to) put the builds (and workspace
> I assume) in the Git repository, since it is not scalable.


>From my understanding of the potential failure scenarios with a plugin or core
upgrade is that unreadable build.xmls won't present a problem, or be mutated by
a new plugin update, correct?

If that's the case then I don't see a problem with leaving them out of the
snapshotting system. Generally speaking, I believe we should be mostly tracking
data which will be mutated on upgrade, or other potentially high importance
data.


> I'm in mind to adjust the JEP with that proposal, though it somehow
> conflicts with that statement in the JEP-301 that "all mutable state and
> data will be written and stored in JENKINS_HOME
> <https://github.com/jenkinsci/jep/tree/master/jep/301#mutable-data>".


When I wrote `JENKINS_HOME` I was actually just using that as a short-hand for
what is commonly understood as `/var/lib/jenkins` to most people. Basically,
mutable state should not be scattered around inside the container's temporary
filesystem, but rather contained in the single mounted volume, e.g.:

docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen


So long as we're mounting everything through a single volume mount for the
container, my concerns/requirements for JEP-301 are met. Does that make sense
to you Ba(p)tiste?


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/20180315162720.ce7bbd67l2lu6yaz%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [JENKINS-49406] Evergreen snapshotting data safety system pre-JEP: feedback welcome

[R. Tyler Croy]

(replies inline)

On Wed, 14 Mar 2018, Baptiste Mathus wrote:

> Hello everyone,
> 
> For Jenkins Essentials
> <https://github.com/jenkinsci/jep/tree/master/jep/300>, one critical
> requirement is to be able to upgrade, and hence rollback in an automated
> manner.
> So, as we are committed to an open design
> <https://github.com/jenkins-infra/evergreen#open-design> process, I have
> written a first draft of the associated Jenkins Enhancement Proposal.
> 
> It is up for review at https://github.com/batmat/jep/pull/1
> 
> I am very eager for any kind of feedback there.
> I am especially interested in catching & clarifying (more or less) glaring
> holes in that design.


Thanks for taking the time to send this out Ba(p)tiste! Now that I've had a
chance to take a look, I think the one thing that's missing from this document
is a bit more explanation of the problem which requires this solution.

My take on this problem space is that core and plugin upgrades can result in
modification of config.xml and other object-serialized-files on disk when an
upgrade occurs. As these files are serialized from objects in memory, when an
internal API changes within a plugin/core, it will necessarily result in
changes to files on disk. These changes may not be safe to "rollback" from,
i.e. Plugin A v0 cannot load a file generated by Plugin A v1.

This means an upgrade of Jenkins Essentials has a very real potential to cause
irreversible modifications to files on disk which prevent a safe rollback.


So that type background/context is (IMHO) missing a bit from the JEP document.

I think the Motivation section should also explain a bit more explicitly that
"bricking" a Jenkins Essentials instance is a severe failure for the project,
and thus we need to prevent against irreversible modifications to files causing
runtime failures for the Jenkins Essentials installation.


Overall, I think this looks quite reasonable. I look forward to seeing the
implementation and tests we get to write to support it :)


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/20180314175527.yeofyld6a2d2p4ro%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Thoughts on sending error telemetry for Jenkins Essentials

[R. Tyler Croy]

I just wanted to make sure I shared an update on this thread. I have filed the
following ticket (https://issues.jenkins-ci.org/browse/JENKINS-49805) to
capture some of the prototyping work necessary here.

I expect we'll have a draft JEP coming up after the prototyping work is done.


Thanks for the ideas and feedback everybody!



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/20180301001723.rhhvyfhwpxthmsnx%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Thoughts on sending error telemetry for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Wed, 21 Feb 2018, Robert Sandell wrote:

> Or if you've ever seen one of these panels at the checkout counter in a
> store somewhere
> 
> http://customerstrategy.net/customer-experience-improvement-systems-part-1/


Heh, I've seen those outside bathrooms, which I find kind of gross; I'm not
touching those buttons. :)

I understand the potential utility in the system proffered by jglick, so I will
keep that idea in mind, but punt it down the road for when we need to better
understand our users' relationship with Jenkins Essentials, rather than the
system itself.

Right now my primary focus is on automating the collection of useful telemetry
about the system in aggregate. Once that is in place I'm happy to entertain
further iterations to gather more fine-grained information.


- 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/20180221164517.jdkahnhh6am22kmf%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Thoughts on sending error telemetry for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Sat, 17 Feb 2018, Baptiste Mathus wrote:

> Le 16 févr. 2018 15:51, "R. Tyler Croy" <[1]ty...@monkeypox.org> a écrit :
> 
> 
> One of the necessary details, in my opinion, to make Jenkins Essentials 
> [0]
> successful is providing near-real-time error telemetry. Coupled with the
> "Evergreen" distribution system [1], error telemetry "post-deploy" will be
> absolutely crucial to determine whether or not we have just pushed out bad
> code
> worthy of reverting.
> 
> I currently define "error telemetry" to include:
> 
>  * Uncaught exceptions which cause the Evil Jenkins 500 page
>  * Logged ERROR messages, with or without exceptions
>  * Logged WARN messages, with or without exceptions
> 
> 
> 
> Totally agreed automated reporting is a must.
> 
> Shouldn't the evergreen client send feedback too? Like if it triggered a
> Jenkins restart and never heard back since?


Your questions are definitely on the right track but I have been mentally
segmenting Jenkins _error_ telemetry from "generalized telemetry." For example,
my thinking recently evolved to change an "update" service to a "status"
service to more thoroughly accomodate the "status" from evergreen-client (for
example, is the Jenkins online, what version, how long has it been online,
etc).

> How about also a less automated /form/ in the Jenkins UI itself, to be used by
> human in case something is clearly wrong but didn't cause logs or outages.
> About that probably a clear web ui somewhere in case everything went wrong.

I like the idea theory, but in practice I believe we would get a tremendous
amount of low-signal "bug reports" through any such functionality and I don't
have the capacity to triage and handle that kind of feedback from users, thus
the automated routes :)


> General thought/note: this probably will require some setup to avoid attackers
> can trigger an auto-revert by sending bad reports to the telemetry endpoint.

Well certainly, "don't 100% trust client data" should be a foundational
principle for most applications :)


As an aside, your mail client sure likes to do non-standard quoting and inline
replies :/




> 
> 
> 
> This list is by no means set in stone, and it is expected that there's
> going to
> be some "noise" in the system, so rooming upstream of this error telemetry
> won't be looking for the presence of errors but rather tracking patterns
> over
> time [2].
> 
> 
> The big challenge that we have, for which I wanted feedback, is *how* we
> can
> acquire this error telemetry
> 
> 
> My first prototype in this area was a plugin which integrates with the
> Sentry[3] error reporting service: [2]https://github.com/jenkinsci/
> sentry-plugin
> This approach basically spins up a background busy-waiting thread which
> loops
> over all the loggers in the JVM, and adds the SentryHandler to loggers. 
> Not
> the
> prettiest solution but it mostly works. There is an opportunity to miss
> logged errors before the SentryHandler is added, but it's hard to quantify
> how
> serious a gap that might be.
> 
> I am not /thrilled/ with this approach, but it meets a very important
> criteria in
> that it's non-invasive to core and other plugins and can simply be
> installed in
> a Jenkins instance in order to work.
> 
> 
> I wanted to ask for more thoughts on alternative approaches, if they 
> exist,
> which would enable the collection of the error telemetry discussed above.
> I'm
> sure there's something I'm missing.
> 
> 
> 
> 
> [0] [3]https://github.com/jenkinsci/jep/tree/master/jep/300
> [1] [4]https://github.com/jenkinsci/jep/tree/master/jep/300#auto-update
> [2] For example: [5]https://itmonitor.zenoss.com/
> is-your-performance-normal-how-do-you-know/
> [3] [6]https://sentry.io
> 
> 
> Cheers
> - R. Tyler Croy
> 
> --
>      Code: <[7]https://github.com/rtyler>
>   Chatter: <[8]https://twitter.com/agentdero>
>      xmpp: [9]rty...@jabber.org
> 
>   % gpg --keyserver [10]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 [11]jenkinsci-dev+unsubscr...@googlegr

Re: Using 'outside collaborators' to manage permissions on GitHub

[R. Tyler Croy]

 but I don't expect that this will affect many 
> teams. Effective repo permissions will be retained. Teams for 
> cross-repository permission management by project teams like Blue Ocean can 
> be recreated on request.
> 
> Dealing with org membership
> ---
> This is admittedly of secondary interest to me, as membership does not grant 
> permissions, but I think you should be able to an org member iff you're a 
> contributor to Jenkins or its plugins.
> 
> This means that???
> - we invite people to join the jenkinsci org when we invite them as a 
> collaborator to a repo via the bot. I think these invitations are independent.
> - we periodically invite people to join the org if they are currently outside 
> collaborators (e.g. manually added) and aren't already invited to join.
> - we periodically remove people from the organization that are not members of 
> any team, or outside collaborators to any repository.
> 
> If these points are contested, I'd be happy to exclude this from the current 
> proposal. This would just mean that future newcomers to the project would 
> probably get no opportunity to join the GH organisation, however.
> 
> 
> 1: 
> https://groups.google.com/forum/#!msg/jenkinsci-dev/ksKAsmsmVng/lG2lNEaJBQAJ
> 2: 
> https://groups.google.com/forum/#!msg/jenkinsci-dev/p1QEin62S7M/v2ALl9A5BQAJ
> 3: 
> https://groups.google.com/forum/#!msg/jenkinsci-dev/UMzB3DMiyrs/UgMXfq-1BQAJ
> 4: 
> https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/
> 5: https://help.github.com/articles/about-team-discussions/
> 
> -- 
> You received this message because you are subscribed to the Google 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/39D18ABD-ADA2-44A4-9872-0FB3284BF2C4%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.

- 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/20180217201012.5bmdpx3siusso7qt%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Request for participation: Jenkins Security Officer candidates

[R. Tyler Croy]

I was reminded today that I completely forgot to send out an update on this! My
apologies, time flies when you're having fun I suppose.

I would like to thank the candidates who spoke up and offered their time to act
in the capacity as the Jenkins Security Officer. The board has selected Daniel
Beck to continue on as the Jenkins project's Security Officer.

Since the failure was on the communication part, not the decision making part,
I have updated the wiki to reflect that Daniel's term actually started in
December. See 
<https://wiki.jenkins-ci.org/display/JENKINS/Governance+Board#Officers>

For more information about Jenkins CERT or our responsible disclosure policies,
please see: https://jenkins.io/security/



Thanks Daniel for your continued work to make Jenkins more secure \o/




On Fri, 08 Dec 2017, R. Tyler Croy wrote:

> Time flies when you're having fun, and or, releasing a whole bunch of security
> advisories and patches :)
>
> I should thank Daniel Beck for leading CERT over the past couple years in his
> tenure as the Jenkins Security Officer. Jenkins is more secure than effort
> thanks to his, and others', diligent efforts.
>
> In accordance with our previously agreed upon team lead proposal
> (https://wiki.jenkins-ci.org/display/JENKINS/Proposal+-+Project+sub-teams)
> I am now asking, again, on behalf of the Jenkins board[1] for candidates who
> are willing to act as the Jenkins Security Officer.
>
> The responsibilities of the Jenkins Security Officer would be to lead Jenkins
> Security (CERT) team, and:
>
> * Run the Jenkins CERT meeting
> * Manage sending gifts to qualifying reporters of resolved security issues [2]
> * Coordinate work on, and releases, of security fixes with plugin authors,
>   Kohsuke and the LTS team lead
> * Publish Security Advisories (including CVE IDs and CVSS) and notify the 
> mailing
>   list
> * Drive security policy definition/changes in the community
> * Represent the Jenkins project on security topics with third parties
>
>
> The expected term of the Security Officer would be 12 months.
>
>
>
> Contributors interested in being considered for the Jenkins Security Officer
> position should email the board: jenkinsci-bo...@googlegroups.com in the *next
> seven days* explaining their qualifications for the position.
>
> In seven days the board will select a candidate to appoint to the position who
> will be able to act on behalf of the Governance Board on matters pertaining to
> the position described above
>
>
> Thanks!
>
>
> [0] https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CERT+team
> [1] The current board: 
> <https://wiki.jenkins-ci.org/display/JENKINS/Governance+Board>
> [2] 
> https://wiki.jenkins-ci.org/display/JENKINS/Rewards+for+reporting+security+issues
>
> - R. Tyler Croy
>
> --
>  Code: <https://github.com/rtyler>
>   Chatter: <https://twitter.com/agentdero>
>
>   % 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/20171208194139.omtoenz67zlttauo%40blackberry.coupleofllamas.com.
> For more options, visit https://groups.google.com/d/optout.



- 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/20180217200547.ncmtpgwwi6lajubd%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Thoughts on sending error telemetry for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Fri, 16 Feb 2018, Jesse Glick wrote:

> On Fri, Feb 16, 2018 at 9:51 AM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > I currently define "error telemetry" to include:
> >
> >  * Uncaught exceptions which cause the Evil Jenkins 500 page
> >  * Logged ERROR messages, with or without exceptions
> 
> Absolutely.
> 
> 
> >  * Logged WARN messages, with or without exceptions
> 
> Possibly. Cf.
> 
> https://github.com/jenkinsci/jenkins/blob/09e1f8cd0ca173f3526f016e9ff18410fb422807/test/src/test/java/jenkins/model/StartupTest.java#L38-L45
> 
> But beware that the list of plugins which emit rather spurious
> `WARNING`s is pretty long at the moment. I guess we will have the
> chance to start fixing those cases among Essentials plugins, but how
> do you plan to filter out cases coming from ???inessential??? [am I
> allowed to say that?] plugins over which we have little control?


Indeed! I've seen, and reported, a lot of these spurious warnings in JIRA based
on my work with the "Code Valet" experiment/prototype. Fortunately most
developers be fine with tweaking the log levels for spurious WARNING logs which
might confuse the already beleaguered Jenkins administrator :)


> > a background busy-waiting thread which loops
> > over all the loggers in the JVM, and adds the SentryHandler to loggers.
> 
> Huh?? All you need to do is add a handler to the root logger, once at
> startup (say in an `@Initializer`). That will receive records sent to
> any sublogger.


Heh, I'm aware that it's not a good approach, thus my questions here.

See also: http://littlefun.org/uploads/52309db3e691b236df7d6b76_736.jpg


> To Bobby???s response, well yes you would miss some early messages that
> way, but Jenkins core is already capturing a bunch of records at
> `INFO`+
> 
> https://github.com/jenkinsci/jenkins/blob/09e1f8cd0ca173f3526f016e9ff18410fb422807/core/src/main/java/hudson/WebAppMain.java#L84-L295
> 
> so in your initializer you can check for anything interesting in that
> buffer too. Anything in Jetty startup prior to `contextInitialized` is
> unlikely, and these would typically not be bugs in software we were
> updating via Evergreen anyway.
> 
> 
> Anyway, +1 for concept. Will this be a JEP?


Definitely! This will be in a JEP as my goal is to provide comprehensive design
documents (via JEP) for as much of Jenkins Essentials as possible for two
reasons: it's the right thing to do, and also it helps me identify gaps and
build a better thing.


Thanks Jesse and Bobby for the ideas, I'll experiment with the custom logger
configuration file approach and verify that it will work as suggested.


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/20180216161728.kx7vnfcgtrcrtcni%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Thoughts on sending error telemetry for Jenkins Essentials

[R. Tyler Croy]

One of the necessary details, in my opinion, to make Jenkins Essentials [0]
successful is providing near-real-time error telemetry. Coupled with the
"Evergreen" distribution system [1], error telemetry "post-deploy" will be
absolutely crucial to determine whether or not we have just pushed out bad code
worthy of reverting.

I currently define "error telemetry" to include:

 * Uncaught exceptions which cause the Evil Jenkins 500 page
 * Logged ERROR messages, with or without exceptions
 * Logged WARN messages, with or without exceptions

This list is by no means set in stone, and it is expected that there's going to
be some "noise" in the system, so tooling upstream of this error telemetry
won't be looking for the presence of errors but rather tracking patterns over
time [2].


The big challenge that we have, for which I wanted feedback, is *how* we can
acquire this error telemetry


My first prototype in this area was a plugin which integrates with the
Sentry[3] error reporting service: https://github.com/jenkinsci/sentry-plugin
This approach basically spins up a background busy-waiting thread which loops
over all the loggers in the JVM, and adds the SentryHandler to loggers. Not the
prettiest solution but it mostly works. There is an opportunity to miss
logged errors before the SentryHandler is added, but it's hard to quantify how
serious a gap that might be.

I am not /thrilled/ with this approach, but it meets a very important criteria 
in
that it's non-invasive to core and other plugins and can simply be installed in
a Jenkins instance in order to work.


I wanted to ask for more thoughts on alternative approaches, if they exist,
which would enable the collection of the error telemetry discussed above. I'm
sure there's something I'm missing.




[0] https://github.com/jenkinsci/jep/tree/master/jep/300
[1] https://github.com/jenkinsci/jep/tree/master/jep/300#auto-update
[2] For example: 
https://itmonitor.zenoss.com/is-your-performance-normal-how-do-you-know/
[3] https://sentry.io


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/20180216145116.yizslgftmjgnhwmn%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Evergreen packaging for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Thu, 15 Feb 2018, Carlos Sanchez wrote:

> yay! +1
> 
> I agree with previous comments that it is not ideal to run multiple
> processes and that in a kubernetes world this would possibly be a Pod with
> two containers, but I think it's important to get something out and
> iteratively improve.
> A decent user experience today means just one container and we can always
> had a Pod definition for Kubernetes users if we find that useful in the
> future.
> 
> Regarding different environment autodetection it would be nice, but having
> a way to manually select it (system property, env var,...) would be good
> enough for now

Contemplating jglick's feedback further, I am more in agreement with his point
about providing disparate "flavors" to tailor the experience further for
user-success on cloud environments such as Azure or AWS. To that end I've
updated JEP-300: https://github.com/jenkinsci/jep/pull/58

The detail which makes this important is the suite of plugins necessary to
include "out of the box" to provide the Automatic Sane Defaults will change
depending on the environment. If we can detect AWS, then we can make sure we're
downloading the S3 plugin, for example, but on Azure we wouldn't want to bloat
the user's environment with it. Rather, Azure users should have the Azure VM
Agents and Azure Container Agents plugin included by default.


I will target AWS with the first "flavor" and then we can see where that takes
us.



Thanks for the feedback Carlos!



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/20180215174522.ewqpuvbmjxchuj3j%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Accelerating Jenkins development with Jenkins Essentials

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


signature.asc
Description: PGP signature

Re: Accelerating Jenkins development with Jenkins Essentials

[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/20180214182600.56ebwim6vx44ljfk%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Evergreen packaging for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Wed, 14 Feb 2018, Jesse Glick wrote:

> On Tue, Feb 13, 2018 at 7:03 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> > I have been thus far deriving jenkins/evergreen from
> > jenkins/jenkins simply to inherit some scripts, permissions, and other bits.
> 
> Yeah, that makes sense as a way to get things up and running quickly.
> Once we have an accepted process for tagging a ???release??? of ???Jenkins
> Essentials??? as a whole, as implied by
> 
> https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#auto-update
> 
> then we can rewrite the image to handle core consistently.
> 
> >> I do not think it is wise to try to automagically detect a cloud
> >> environment. [???]
> >
> > [???what are your concerns] regarding
> > a singular "all-in-one" package which can include the necessary 
> > cloud-detection
> > auto-configuration tooling?
> 
> A general distrust of anything magical and opaque that might or might
> not work depending on factors too complex for users to see or
> understand. If we have a recommended way for Jenkins to run in AWS,
> polish it up and put it on Marketplace, if possible. If we have a
> recommended way for Jenkins to run in a self-managed Kubernetes
> cluster, publish an official Helm chart for it. But keep the basic
> Docker image, i.e., whatever happens when I run something like
> 
> docker run --rm -v jh:/var/jenkins jenkins/evergreen
> 
> straightforward and predictable.
> 
> If you are worried about discoverability of our preconfigurations, you
> can always add an `AdministrativeMonitor` that says something like
> 
> > Hey there! From sniffing around, it looks like you are running this Jenkins 
> > service in Azure, but you are not taking advantage of the preintegration 
> > work we have done for you.
> > For more information, see: https://azuremarketplace.microsoft.com/etc.
> > [[Dismiss]]



Yeah, this is where I thought you were going with the original feedback and I
agree, it's probably a good idea if for no other reason than to reduce the
opportunity for unintend side effects. I'll look at how I can work this nuance
into the JEP-300, I agree it's important to view different target platforms
(AWS, Azure, Kubernetes) differently and worth capturing that in this overview
document.



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/20180214151009.paa3jmyl3n3o53ea%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Accelerating Jenkins development with Jenkins Essentials

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


> 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 :)


> 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: <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/20180214000422.hkio3rohqdgzn4pd%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Evergreen packaging for Jenkins Essentials

[R. Tyler Croy]

(replies inline)

On Thu, 08 Feb 2018, Jesse Glick wrote:

> https://github.com/jenkinsci/jep/blob/master/jep/301/README.adoc#plugins
> 
> does not make sense to me. A critical benefit of this system as I
> understood it was that we could deliver a complete software
> package???including Jenkins core and plugins???as a unit. So why are you
> treating core and plugins as distinct things? You should either
> 
> · Package a particular version of core, and of all ???essential???
> plugins, together in a particular version of a Docker image, and have
> people use a new tag of this image when they want to update anything.
> That would be the normal way to manage software in Docker, though it
> appears to contradict your intention of using `evergreen-client` to
> perform upgrades.
> 
> or
> 
> · Have the image contain only the supervisor, and have it download
> specific versions of Jenkins core and plugins on demand; and update
> the image itself only when the supervisor changes (presumably rarely).
> That also bypasses the concern noted in #security as the image would
> not need to be updated merely because of a core security advisory.


I apologize for the delay, I needed some time to think about and understand the
points you're raising here. I think we're conceptually on the same page, and
it took a bit of thinking and consultation with Kohsuke to help me fully
understand your feedback here.

I think the design document was unclear, and had a hidden premature
optimization/assumption. I have been thus far deriving jenkins/evergreen from
jenkins/jenkins simply to inherit some scripts, permissions, and other bits.
This is definitely not necessary, and I agree the packaging should follow the
second approach you describe, more or less:

 1. Come online
 2. Grab the latest, greatest, and secure-iest bits
 3. Do a Jenkins \o/

I will make the JEP-301 document more clear on that.


> https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#sane-defaults
> 
> I do not think it is wise to try to automagically detect a cloud
> environment. Rather, we should offer variant images which are
> preconfigured for specific environments like AWS. Or offer startup
> flags etc. to select such preconfigurations, and tailor the
> installation scripts for those environments to pass the right flag.


I /think/ I understand where the reasoning would be for "flavors" depending on
the cloud environment (for example), but to make sure I'm not making any more
assumptions, would you mind expanding a bit on what your concerns are regarding
a singular "all-in-one" package which can include the necessary cloud-detection
auto-configuration tooling?


Thanks for taking the time to review both documents and provide thoughtful
feedback. I'll try to improve on my delay times, work responsibilities, you
know the drillThanks for taking the time to review both documents and provide
thoughtful feedback. I'll try to improve on my delay times, work
responsibilities, you know the drill.


*looks wearily at google calendar*

I'll try to land some updates to the prototype and these design documents with
your feedback tomorrow (Feb 14th).



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/20180214000359.x72xio6o5m6qads3%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Proposal: Add optional "Released as" and "Stage Release" states to JIRA

[R. Tyler Croy]

I had a conversation with Oleg about this last week in the #jenkins-community
channel, which I promised I would summarize here. After reading the JEP and
discussing with Oleg a bit, I think this is a reasonable enhancement and has
little to no negative impact, so +1.

The primary question I had was wheter JEP-3 would continue to be relevant if 
Blue
Ocean, or Pipeline for example, were moved into separate JIRA projects. In
essence, would the "problem be solved" if we moved those specific plugin
subsystems to separate JIRA projects where they could consistently use the
built-in functionality within JIRA for managing versions and releases. Oleg's
proposal is still relevant and beneficial to the "long-tail" of smaller plugin
systems, and individual plugins, which may never merit a single JIRA project
unto themselves.

So yeah, +1 from my perspective to JEP-3 :)


Full log below.

01:58   rtyler: pong
02:02   I was reading JEP-3 and a question came to my mind, if we had a 
separate project in JIRA for Pipeline and one for Blue Ocean (for example), 
JEP-3 would 
still be necessary in your mind wouldn't it?
02:31   It would
02:34 @ for JENKINS probably, the specific projects could do it via 
versions
02:36   Yes, BlueOcean could switch to versions
03:10   I have some reservations about moving BO to a separate 
project tho
03:11   Needs to be impkemented properly so that other plugin 
maintainers are not affected
03:14   why would that negatively affect other plugin maintainers?
04:14   rtyler: Moving issues is generally more complicated than 
changing the components, and it takes more time. For multi-project issues (e.g. 
   BlueOcean+SSE Gateway or BlueOcean + JIRA) it will also 
require some linking between issues and other such fun
04:17   rtyler: There is a request from i386 about that 
somewhere in the mailing lists, cannot find it. Maybe i386 wants to recover the 
thread for 
   further discussion. CC danielbeck who participated in 
the thread as well IIRC
04:21   BTW, I am not sure whether comments like "I moved to 
AppVeyor" are appropriate when a core maintainer says so :( 
   
https://github.com/jenkinsci/change-assembly-version-plugin/pull/17#issuecomment-364553617
04:21   But .NET stack for Jenkins is really abandoned
04:22   It needs a hero. A full-time hero actually, so /me shrugs
04:37   oleg-nenashev: I don't think i386 is going to recover the 
thread, I think he was pretty frustrated with all of us for using JIRA shittily
04:37   (which we kinda are, for a number of reasons)
04:38   yeah
04:38   I agree with that
04:38   oleg-nenashev: so I was just curious whether other changes made 
JEP-3 still relevant, and it seems like JEP-3 is
04:38   so I'm going to summarize this discussion and reply to the dev 
list thread, okay?
04:38   fine with me
04:39   Generally I need somebody who is willing to be a BDFL 
candidate
04:39   danielbeck or ogondza seem to be obvious candidates 
since they handle the core JIRA crap, but they didn't reply so far. Maybe you 
or ulli?
04:40   I don't think I spend enough time in JENKINS to rightfully 
quality, sorry
05:50   np




- 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/20180212175616.dntzdyauekyb3kps%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature