CAcert Code Development list.

[Ian G <iang AT cacert.org>]

On 5/02/2015 15:34 pm, Jan Dittberner wrote:
> Hello,
>
> I setup a Jenkins [1] instance [2] that can be used for building policy
> documents and perform other automated tasks (CCing cacert-devel to make the
> developers aware). The first job of Jenkins is a build job for the policy
> build tool by Felix Dörre [3] that was created in parallel to my previous
> idea with Sphinxdoc and makes plain text policies even easier.
>
> [1] http://jenkins-ci.org/
> [2] https://jenkins.cacert.org/
> [3] https://jenkins.cacert.org/job/cacert-policy-parser/
>
> I added Martin and Benny as Jenkins admins and created an account for Eva
> too (you get initial account information via private mail). I setup Jenkins
> to allow new user registrations [4] so that all interested people can get
> read access. When you need more permissions you can just send a mail to
> jenkins-admin AT cacert.org.
>
> [4] https://jenkins.cacert.org/signup
>
>
> The next step should be to define the workflow that we want to build there.
> My idea is something like this:
>
> 1.) Manage the policy source text files in either SVN or Git (should be
>      decided by the people that will work on the policy texts)
>
> 2.) Create a Job that looks for changes in the repository from step 1 and
>      builds the HTML representation with Felix' tool
>
>      Jenkins allows viewing of the build results in a browser so this might
>      be sufficient for snapshots of the generated policy documents.
>
> 3.) Setup an additional Jenkins job that allows a one (or two) click
>      publication of a chosen policy document to the target (to be decided
>      but my impression is that git publication to a separate subdomain like
>      policies.cacert.org on webstatic would be easy). That Jenkins job would
>      be the official "ceremony" to publish policies and should be executed by
>      the policy officer.
>
> Do you agree with this idea and should I / we continue with such a setup?


Personally I would be very cautious about separating policy into 
"source" and "HTML".  I don't see the need, and there are good reasons 
not to do this.  Boring as it may seem, primitive as it may seem, we are 
trying to achieve "nothing up our sleeves" with policy which means there 
is a benefit in working in raw HTML.

I don't understand the need for Jenkins.  As far as I saw it, what we 
wanted was a simple tool that did an SCP from our repo (be it SVN or 
git) to the raw static directory which was served as a website. Run by 
PO when and if she needs it.

I cannot see a need for anything beyond that yet.  A quick scan of the 
Jenkins wiki doesn't enlighten -- what feature is being sold here as 
being useful?

What would be nice is a tool that takes two drafts, or draft + POLICY 
and presents a diff format.  But I hesitate to say that because I think 
it is far more important to get our simple static site and SCP up and 
going, 100 times more important than worrying about how we do workflow.

However, I'll go with whatever the PO and policy group decides.




iang