Andy Doan andy.doan@linaro.org writes:
On 11/29/2012 04:34 AM, Paul Sokolovsky wrote:
Hello,
On Wed, 28 Nov 2012 08:31:41 +1300 Michael Hudson-Doyle michael.hudson@linaro.org wrote:
[]
I am hoping we can find some time to improve this with an API on https://snapshots.linaro.org that would be authenticated directly, but we can't make promises on when that's going to be around.
Sounds like all the more reason to keep the job file at the fairly abstract "publish" level then.
Yes, I also fully agree with this idea. And it also clear that we need to support different methods of publishing - test/devel and production, old and new, etc. So, publish section in job JSON def would accept identifier of publishing method, like "method"/"location"/"destination", whatever:
{ "command": "publish", "parameters": { "location": "snapshots", "pattern": "build/product/*/out/*.tar.*" } }
Seems about right - without me *really* thinking into the issue :)
That location key also shouldn't be treated as just a hostname, but rather as identifier of publisher config, which can be for example a subdirectory like:
publisher/<id>/: publish - this gets called by lava with the list of files to do actual publishing ssh_key - a file used by publish script, can be any other files as needed
I'm not a huge fan of this, but I don't really have a better suggestion to offer.
Yeah, I think this seems OK to me.
Cheers, mwh
Of course, the above is just a guess how it can be done, please use whatever suits LAVA paradigm well, but it would be nice to get "devel" publishing to mombin with existing LAVA setup soon, and "production" publishing later, so some way of abstracting publisher support is definitely needed. Please let us now if Infrastructure can help with org side of this, like submitting a ticket or blueprint for this.
I think you are on the right track. I think the best way you could help here, would be to submit a patch for this.