Hi, first of all, thanks for providing a great service -- I'm happy that I can build packages for a ton of distributions from just a small set of input files.
I've learned that it's possible to automate the rebuilds in a pretty impressive way -- starting with a proper _service file [1] takes care of fetching the new sources and adding a wrapped curl command [2] as a post-receive hook triggers the rebuilds on each push to my git repository.
However, I suspect that using the public OBS instance as a poor-man's CI system is not what you guys really want people to do. Given that I have enabled essentially all repository configurations which are currently supported, I can imagine that receiving a request for a full rebuild of 20 versions of a package ten times a day is something that is behind the threshold of the acceptable use.
Could you please either tell me "hey, just do that, it's fine, we have plenty of power", or name a reasonable limit on how many rebuilds a day I can ask for? I'll be happy to limit the rate to, say, one request per minute/hour/day/week/month/year/... if that's what is acceptable.
With kind regards, Jan
[1] https://build.opensuse.org/package/view_file?file=_service&package=troji...
[2] The relevant part of the post-receive hook (behold the shell XML handling, oh yes!):
echo -n "Triggering the OBS rebuild... " OBS_REQ_RESULT=$(curl --user jkt-git-auto-requestor:XXX -X POST -H "Content-Length:0" -s -S 'https://api.opensuse.org/build/home:jkt-gentoo:trojita?cmd=rebuild&packa...') if [[ "${OBS_REQ_RESULT}" == "<status code="ok" />" ]]; then echo " OK." else echo " Error: ${OBS_REQ_RESULT}" fi
On Fri, Jan 11, 2013 at 07:36:38AM +0100, Jan Kundrát wrote:
echo -n "Triggering the OBS rebuild... " OBS_REQ_RESULT=$(curl --user jkt-git-auto-requestor:XXX -X POST -H "Content-Length:0" -s -S 'https://api.opensuse.org/build/home:jkt-gentoo:trojita?cmd=rebuild&packa...') if [[ "${OBS_REQ_RESULT}" == "<status code="ok" />" ]]; then echo " OK." else echo " Error: ${OBS_REQ_RESULT}" fi
As you are using a service, shouldn't you use the runservice call?
Newer osc have a built in command, older must fall back to an API call: osc api -m POST "source/home:xxx:yyy/pkg?cmd=runservice"
Regards, Martin
On Friday, 11 January 2013 09:22:16 CEST, Martin Koegler wrote:
As you are using a service, shouldn't you use the runservice call?
I picked up the first thing which was described in the API guide and worked.
Newer osc have a built in command, older must fall back to an API call: osc api -m POST "source/home:xxx:yyy/pkg?cmd=runservice"
The repository is hosted on RHEL6, using curl is preferably to having to setup the OSC client.
Cheers, Jan
Actually, please, tell why do you need rpm package for each push? Are you going to use auto-deploy after this? Or just for build-check. If the latter, I think https://travis-ci.org is what you really need.
On Friday, 11 January 2013 09:42:29 CEST, Matwey V. Kornilov wrote:
Actually, please, tell why do you need rpm package for each push?
I don't. My primary motivation is to get daily builds out to the users, so the "once a day" frequency is enough. The nice side effect of being able to verify whether building against old Qt 4.6.x (as shipped in RHEL6) still works is a welcome advantage as well, though.
It's just that adding the trigger to the post-receive hook was the easiest thing for me to do (and as usual, getting to know that a particular commit fails as soon as possible cannot hurt, either).
Are you going to use auto-deploy after this? Or just for build-check. If the latter, I think https://travis-ci.org is what you really need.
That's something I wasn't aware of, thanks for sharing a link. (The big disadvantage for me is their AJAX-heavy interface, it didn't work at all in rekonq, worked half way with Opera and only offered all functionality in Firefox). It also looks like their selection of platforms is a bit limited compared to OBS.
With kind regards, Jan
buildservice@lists.opensuse.org