Improve human-readability of jobs on Jenkins' side

[Paul Sokolovsky]

Currently, backend passes build config to Jenkins in base64 encoded form. Unless there're security concerns, it would make sense to make it more discernible on Jenkins side, by using for example urlencoding (%xx).

Caveat: command-line encoder/decoder availability - base64 util is used now, but we always could use Python.

[Michael Hudson-Doyle (mwhudson)]

The main constraint here is that the encoded form can't contain newlines, because jenkins squashes them in the config xml. url encoding is probably less opaque than base64 though, I'll grant :)

[Paul Sokolovsky (pfalcon)]

We can also fill in jenkins job description with the build config and link back to frontend page.

[Alexander Sack (asac)]

whats the benefit of improving the UI/readability on jenkins side of our build service?

[Paul Sokolovsky (pfalcon)]

On Tue, 04 Oct 2011 13:27:33 -0000
Alexander Sack <email address hidden> wrote:

> whats the benefit of improving the UI/readability on jenkins side of
> our build service?

As usual - more human insight into system data flow, less
confusion, productivity improvements. But since the time this bug was
submitted, I started to think that maybe base63 encoding is kind of
"protection" to ensure that we have single point for build config
changes - via frontend. So, now I'm not sure I want to change this, not
without a discussion like this for sure (and least priority anyway).

>

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

[Alan Bennett (akbennett)]

Due to the age of this issue, we are acknowledging that this issue will likely not be fixed. If this issue is still important, please add details and re open the issue.