Log more information about the build environment and results #497
Conversation
When testing OBS behaviour changes, it's useful to be able to look at a build log and see which code was running. Signed-off-by: Simon McVittie <[email protected]>
debootstrap is not a simple command, and there are some subtleties to
the options we use, so we should log exactly what we did.
The incantation with `$(printf ' %q' "$@")` is to log the contents
of $@, correctly shell-quoted to avoid ambiguity (in case there are
spaces in an argument). It should expand to something like
running debootstrap: chroot /buildroot debootstrap --etc --etc...
Signed-off-by: Simon McVittie <[email protected]>
If packages fail to unpack or configure during the preinstall step, it's useful for the log to indicate precisely which packages were used. Signed-off-by: Simon McVittie <[email protected]>
Debian's sbuild dumps the metadata and contents of all build results into its own logs, which is often helpful when comparing build logs and package contents. Let's do the same. Signed-off-by: Simon McVittie <[email protected]>
This vaguely mimics what Debian's sbuild does, although the precise information given here is different. Signed-off-by: Simon McVittie <[email protected]>
|
We are a bit unsure here if it would not make sense to have build logs between the different build receipes more similar. On the other hand, I see your point of becoming similar to sbuild ... |
|
I think this would be very useful. Knowing the debootstrap command and details of the build chroot would have saved me time with analysing builds in the past. sbuild is very useful as debian package tool and would be great example here. |
|
@smcv @adrianschroeter any prospect of this being merged? |
|
For what it's worth, Mock does basically the same thing for Fedora. The version of mock, as well as all command invocations for bootstrapping the environment, are included in the logs and output produced by Mock. I'd like to see these changes be implemented globally (across all build engines). |
adrianschroeter
force-pushed
the
master
branch
from
e6ebce5
to
2a6beef
Compare
|
@adrianschroeter, could you please have a look at this again? |
|
As a build and integration engineer for Apertis, I can confirm the information printouts which this MR adds (we run obs-build with these patches applied) have saved me a lot of time spent investigating failed builds. For build dependencies, it helped me reproduce the environment in which the build failed. For outputs, I could immediately see if the packages were missing some files without needing to download them. |
|
The only problem with this PR is that it doesn't do it for all the build engines |
|
Does it have to? The RPM part can be done as a separate pull request by someone knowledgeable about RPM (which e.g. I am not, and I think neither is Simon). |
|
I would be hugely shocked if @smcv didn't know enough about how RPM works to implement this logic for the rpm side, since you're not doing very complicated things in here for the deb side either. |
|
a way to solve this would be to introduce a configuration option (in build config) to enable the more verbose output. It does not need to be implemented in all receipes initially. |
Debian's sbuild (which is conceptually similar to obs-build, but specific to deb packages) includes a lot of contextual information in its log, which in practice is very useful when reproducing and debugging build failures that happen on remote infrastructure where the package maintainer doesn't necessarily have shell access.
This branch adds similar information to obs-build:
This makes the build log a lot more self-contained when attempting to reproduce and fix build issues.
It also adds details of the packages that were built (in 3b6e6a2), including their metadata (dependencies etc.) and file lists. Again, this mimics what sbuild does. It could be split out into a separate pull request if preferred.