Am Mittwoch, 20. November 2013, 10:24:33 schrieb Greg Banks:
G'day,
Second attempt at sending, this time with no HTML. In the 21st century.
So I've been trying to use OBS source services for my project novaprova
https://build.opensuse.org/project/show/home:gnb:novaprova
to do a development tree (i.e. not a release) build on days when there are checkins. What I want is a process which does
1. get the latest source from the master branch in the git repo 2. pull the RPM and DEB package control files (.spec etc) out of a directory in there 3. figure out a version number 4. apply the version number to the .spec file 5. perform build 6. upload build results to repositories
I read this document
http://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Perform_a_nigh...
but I didn't want to do an osc commit for every build, or have a server sitting around whose only purpose was to run a cronjob. So I thought I could do some clever tricks with source services, resulting a single _service file which could be used unmodified for every nightly build. It almost worked. I found the following issues:
1. If the source service runs correctly, there is no visible log. The build log starts after that.
2. If the source service fails, the error messages only appear in a tooltip.
source service support in webui has been removed and yet be reimplemented unfortunatly.
3. The build log page has a bug where it will repeat large chunks of a log.
4. Source services could be better documented. A lot better. For example I discovered @PARENT_TAG@ by reading the source.
feel free to submit updates to the source services...
5. The tar_scm service creates an uncompressed tarball, i.e. foo-git.1234567.tar. My .spec file was expecting a compressed tarball and failed.
6. The recompress service could be used to compress the tarball from tar_scm, but it takes a fixed incoming filename, without wildcards. This doesn't work when tar_scm is generating a tarball filename which has a version number encoded in it, which version number is not known at the time the _service file is written.
No, it does not osc cat OBS:Server:Unstable/build/_service
7. Likewise, the extract_files service could be used to extract a spec file from inside the tarball, but it requires a fixed incoming filename without wildcards. Given that in most projects there will be exactly one tarball, I would have thought that extract_files could have guessed correctly, or accepted a wildcard.
yes, could be added .. patches are welcome :)
8. For the version number, I wanted to use a timestamp in ISO8601 basic format to day precision, i.e. "20131120" for 20 November 2013. The closest I can get is to use %ci as the versionformat in the tar_scm service, but this doesn't quite work. Git gives extended format to second precision withhttps://help.github.com/articles/post-receive-hooks timezone, e.g. 2013-11-20 10:06:35 -0800. The tar_scm script tries to clean this up, but the result still has useless information I don't want and spaces which break the other services.
tar_scm can be configured to use different version schemes via the versionformat parameter. Check the _service file above for an example.
Also, what's a good way to kick off an OBS build from a GitHub webhook?
using tokens and the OBS github plugin. I will document and blog about it these days. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org