Mailinglist Archive: opensuse-buildservice (89 mails)

< Previous Next >
Re: [opensuse-buildservice] Re: osc bl downloads wrong log file
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@xxxxxxx

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >