On Mittwoch, 15. April 2015, 15:22:15 wrote Ruediger Meier:
On Wednesday 15 April 2015, Adrian Schröter wrote:
On Mittwoch, 15. April 2015, 13:13:32 wrote Ruediger Meier: ..
why do you think that the build log would differ much when the result is actually the same?
For example because I have an advanced %check section which runs different tests dependent on what the build host supports. It always run different tests on xen, kvm or whatever machines. Sometimes loading kernel modules is supported, somethimes not, etc.
Once a check fails I always have the same questions:
Was this a random/racy fail? Was this check ever successful on a similar build host. What is the difference between the last failed and the last successful build(s).
okay, I see.
I don't understand how could you find the benefit of full buildlog history questionable.
well, I find it questionable to have a different build log not matching to the build result.
The current log is a log which gave us the same result, so what? The current one would be more easily to reproduce because the chance that similar build hosts and the used packages still exist is much higher.
"osc bl --last" is made to compare the last success with the current failure. Why bothering the packager with an outdated unreproducible buildlog?
this is actually the only reproducable build log. You can use the _buildenv data stored along with the rpms. Okay, this is only true when the used repos do not remove the build binaries, so this works only reliable against openSUSE:*:Update projects.
BTW really confusing is that you get different logfiles in "follow mode" and "download mode". This mode is automatically switched!
feel free to make a github issue for that.
If you want to introduce an entire history for build results, that would be fine. But that would be a new OBS feature.
I will see if I could add that.
Any concept how to organise files on disk and how to access via api should be prepared first. Just to avoid that you write code which will not be merged ....
Look how nice this looks for other build machineries which I'm using: https://travis-ci.org/rudimeier/util-linux/builds
has different problems, the build environment is permanently changing there and you can not reproduce it.... we use it also :)
I know that that there are pro and cons about any existing ci systems that's why I'm using many of them incl. OBS.
Regarding build env I find travis much more stable than OBS. For example the running kernel, CPU etc. stays the same for long periods.
and then it changes to another OS and you can do anything against it;)
For example on OBS you may get a RHEL_4 with kernel 3.16! nowadays.
right, this is why we introduce the support for own kernels in *SUSE distributions meanwhile. If someone takes care to build the kernel-obs-build package pendant for Fedora/RHEL/... I can import and activate them there as well. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, 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