[guardian-dev] [Guardian-internal] Proposal: Public Jenkins

[Abel Luck]

David Oliver:
> So, you DON'T want a "public Jenkins server".  What you want is "public
> availability of the information that comes from our private Jenkins
> server".  Why does that require a 2nd Jenkins server, indeed a "server" at
> all?  Why can't it be just a webpage "here is what happened on our
> full-paranoid Jenkins server today"?
> 
> 

It's a matter of time in the setup cost.

Because there is a plugin (see root of this thread) that publishes info
from a private jenkins to a public jenkins made just for this purpose. I
estimate this would require 1-2 hours to setup and troubleshoot.

The alternative would be writing our own custom HTML scrapers and RSS
feed aggregators to pull the data from the private jenkins then format
it and display it on a public website. I estimate this would require
several man-days of effort to achieve feature parity with my previous
paragraph.

If we want the redmine integration, then add another man-week for
someone to grok and build a redmine plugin for our custom jenkins
slurper platform.

IMHO, simply setting up a public jenkins server that doesn't actually
build anything and rather simply uses the aforementioned plugin to
display information is the most cost effective option.

~abel



> David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
> http://<http://olivercoady.com>
> davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366
> 
> 
> On Fri, Apr 12, 2013 at 3:06 PM, Abel Luck <abel at guardianproject.info>wrote:
> 
>> David Oliver:
>>> Then I am unclear what Abel means at all.  Abel can you help this poor
>>> elder understand?
>>>
>>> Abel: I think it's OK to have a public Jenkins server and here's a way
>>> (plug-in) to make sure only we can edit the info
>>> Hans: To ensure that only we can edit.  Jenkins is not the most secure
>>> piece of software...
>>>
>>> What am I misunderstanding?
>>>
>>
>> Sorry. Here's the breakdown
>>
>> 1. our new build box is our "Secure full-paranoid build server"
>>
>>    our source code and the binaries we compile it into is our lifeblood.
>> Our users trust what we publish. We need to trust what we publish. We
>> can trust what comes out of the secure build server.
>>
>> 2. Our secure build box is our private Jenkins instance
>>
>>    private because it directly handles our source code and binaries
>>
>> 3. the proposed public jenkins server would be a mirror of the
>> _information_ contained in the private instance
>>
>>    While the private server handles our source code and binaries, it
>> produces useful information that the world should know about (e.g., the
>> build status of our projects)
>>
>> Using the plugin I mentioned, the pubic server would never actually
>> touch our sourcecode nor our binaries, but merely mirror the information
>> generated by the private server.
>>
>> ~abel
>>
>>
>>>
>>> David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
>>> http://<http://olivercoady.com>
>>> davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366
>>>
>>>
>>> On Fri, Apr 12, 2013 at 2:56 PM, Hans of Guardian <
>> hans at guardianproject.info
>>>> wrote:
>>>
>>>>
>>>> On Apr 12, 2013, at 2:51 PM, David Oliver wrote:
>>>>
>>>> 1. can we run the public one in the cloud somewhere instead of buying
>>>> another short-useful-lifetime box to decorate our office?
>>>>
>>>>
>>>> No one is talking about more hardware.  Abel wants to put it on the same
>>>> host as dev.guardianproject.info, where redmine is installed.  It
>> seems a
>>>> natural place for it.
>>>>
>>>> 2. Jenkins builds our source code. We are open-source, so we have
>> nothing
>>>> to hide.  As Abel suggests, we only want certain people to edit (for
>> which
>>>> he has a solution).  Thus, why do we need a "full-paranoid" build
>> server at
>>>> all?
>>>>
>>>>
>>>> To ensure that only we can edit.  Jenkins is not the most secure piece
>> of
>>>> software...
>>>>
>>>> .hc
>>>>
>>>>
>>>>
>>>>
>>>> David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
>>>> http:// <http://olivercoady.com/>davidmoliver.com | http://dmo.tel |
>> @davidmoliver
>>>> | +1 970 368 2366
>>>>
>>>>
>>>> On Fri, Apr 12, 2013 at 1:35 PM, Abel Luck <abel at guardianproject.info
>>> wrote:
>>>>
>>>>> Heya,
>>>>>
>>>>> So our desire to be full paranoid wrt the build server is of course
>>>>> justified, but conflicts up against our desire to be transparent in
>>>>> our processes as well.
>>>>>
>>>>> None of the info in Jenkins is confidential, it's just sensitive, we
>>>>> only want approved peeps to be able to edit it.
>>>>>
>>>>> There's no reason the info couldn't be exposed to the world read-only.
>>>>>
>>>>> Of course we don't want to expose the secure Jenkins publicly as that
>> is
>>>>> a huge attack surface.
>>>>>
>>>>> However, there is a plugin called Build Publisher Plugin
>>>>>
>>>>>  "This plugin allows records from one Jenkins to be published on
>> another
>>>>> Jenkins. The typical use case is for you to run builds within the
>>>>> firewall, then send the results to another Jenkins which is facing the
>>>>> outside world. "
>>>>>
>>>>> Proposal:
>>>>> We run a public jenkins instance on the dev.gp.i box, that slurps up
>>>>> data from the private secure jenkins.
>>>>>
>>>>> We could then also integrate jenkins with redmine [2], which will make
>>>>> dev.guardianproject.info the foci of our development effors.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> ~abel
>>>>>
>>>>>
>>>>> [1]:
>> https://wiki.jenkins-ci.org/display/JENKINS/Build+Publisher+Plugin
>>>>> [2]: http://www.r-labs.org/projects/r-labs/wiki/Hudson_En
>>>>> _______________________________________________
>>>>> Guardian-internal mailing list
>>>>>
>>>>> Post: Guardian-internal at lists.mayfirst.org
>>>>> List info:
>> https://lists.mayfirst.org/mailman/listinfo/guardian-internal
>>>>>
>>>>> To Unsubscribe
>>>>>         Send email to:
>> Guardian-internal-unsubscribe at lists.mayfirst.org
>>>>>         Or visit: %(user_optionsurl)s
>>>>>
>>>>> You are subscribed as: %(user_address)s
>>>>>
>>>>
>>>> _______________________________________________
>>>> Guardian-dev mailing list
>>>>
>>>> Post: Guardian-dev at lists.mayfirst.org
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>
>>>> To Unsubscribe
>>>>
>>>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>>        Or visit:
>>>>
>> https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
>>>>
>>>> You are subscribed as: hans at guardianproject.info
>>>>
>>>>
>>>>
>>>
>>
>>
>