Closed ssbarnea closed 4 years ago
We tried to fix this at CI level via https://review.rdoproject.org/r/#/c/27527/6/playbooks/podman/pre.yaml with good results but we realised that would be a really bad idea, as it would involve hacking the operating system and bringing it to an unsupported status (installing ElRepo repositories).
It is much better to implement these changes directly in contrib/build_rpm.sh
where anyone contributing to libpod can use, fix and improve.
@baude @rhatdan @ssbarnea Is this resolved?
20 days ago it was sorted via CI/CD hacks as I mentioned, but AFAIK nobody spared time to implement these steps into in-repo build_rpm.sh script.
Without libpod cores stepping in and assuring that this happens and no regressions are allowed I doubt we have a sustainable way to keep it alive.
RDO&TripleO can assure that the CI/CD is working, but it cannot prevent regressions with a job that is not-voting.
Looking at https://review.rdoproject.org/zuul/builds?project=containers%2Flibpod&pipeline=openstack-regular I conclude that libpod builds rpms only on fedora-31 and not on rhel-8 or centos-8.
CI is running build_rpm.sh
on these platforms where it also has root access, if it fails is almost for sure a fault in libpod.
Sidenote: we did speak about this in our team and we even considered starting to email libpod and post irc notifications on #podman in order to raise awareness.
I just ran it and it is failing because we do not install debuginfo in the spec file. Looking at the build_rpm.sh script , it looks like it does not intend to build them? I don't see that this is something that we did to cause this, but if it was I am willing to be educated.
Installed (but unpackaged) file(s) found:
/usr/lib/debug/.dwz/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64
/usr/lib/debug/usr/bin/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
/usr/lib/debug/usr/bin/podman-remote-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
/usr/lib/debug/usr/libexec/podman/conmon-2.0.0-1591179052.gita17bdf7b.fc32.x86_64.debug
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.c
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/lock/shm/shm_lock.h
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/libpod/oci_attach_linux_cgo.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/pkg/rootless/rootless_linux.c
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/pkg/rootless/rootless_linux.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/drivers/btrfs/btrfs.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/pkg/unshare/unshare.c
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/containers/storage/pkg/unshare/unshare_cgo.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/coreos/go-systemd/v22/sdjournal/journal.go
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/mtrmac/gpgme/go_gpgme.c
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/mtrmac/gpgme/go_gpgme.h
/usr/src/debug/podman-2.0.0-1591179052.gita17bdf7b.fc32.x86_64/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go
Ok I just looked at the failures on centos7, centos8 and rhel8.
We are not planning on shipping any more centos7/rhel7 versions, so these tests should be removed.
The failures are all caused because we are relying on newer versions of OCI Runtimes to add a provides ociruntime to their specfile. runc, crun, kata should all provide this. That would allow podman to run with any runtime. When we release rhel8.3 we will make sure the OCI Runtimes have the proper provides. For now, we can dumb down the spec file to force the use of runc.
A friendly reminder that this issue had no activity for 30 days.
As reported by RDO 3rdPaty CI jobs that run on each PR and also as periodic on master, the ability to build rpms directly from source on these plaforms got broken somewhere during the last two weeks.
All these jobs are relying on
contrib/build_rpm.sh
to perform the rpm building so it is fixable from there.