keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
f62c7665f7
rpm-ostree/ci/build.sh

25 lines
877 B
Bash
Raw Normal View History

ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon
2017-04-28 19:29:25 +03:00
#!/usr/bin/bash
# Install build dependencies, run unit tests and installed tests.
set -xeuo pipefail
dn=$(dirname $0)
. ${dn}/libbuild.sh
ci: Use FAHC for build container Conceptually: we're going to move rpm-ostree and ostree at the same cadence most of the time; for both releases *and* for git master. The problem so far has been the latter part. Reusing FAHC for the build gets us half of the problem. The other trick I realized we can do - just pull ostree out from the build container. This avoids fetching it from the internet, and makes my workflow for hacking on both nicer - I just `sudo make install` in my build container for ostree. It's tempting to make the whole thing symmetric and require `sudo make install` for rpm-ostree and not do the insttree thing but...perhaps after. Closes: #758 Approved by: jlebon
2017-04-28 18:40:22 +03:00
# Use the latest ostree by default
echo -e '[fahc]\nbaseurl=https://ci.centos.org/artifacts/sig-atomic/fahc/rdgo/build/\ngpgcheck=0\n' > /etc/yum.repos.d/fahc.repo
ci: Ensure fahc builds win over base Right now due to rdgo using `git describe` we have `v2017.4.65`, which is lower than `v2017.5`. Closes: #770 Approved by: jlebon
2017-05-08 23:33:21 +03:00
# Until we fix https://github.com/rpm-software-management/libdnf/pull/149
sed -i -e 's,metadata_expire=6h,exclude=ostree ostree-devel ostree-libs ostree-grub2\nmetadata_expire=6h,' /etc/yum.repos.d/fedora-updates.repo
ci: Use FAHC for build container Conceptually: we're going to move rpm-ostree and ostree at the same cadence most of the time; for both releases *and* for git master. The problem so far has been the latter part. Reusing FAHC for the build gets us half of the problem. The other trick I realized we can do - just pull ostree out from the build container. This avoids fetching it from the internet, and makes my workflow for hacking on both nicer - I just `sudo make install` in my build container for ostree. It's tempting to make the whole thing symmetric and require `sudo make install` for rpm-ostree and not do the insttree thing but...perhaps after. Closes: #758 Approved by: jlebon
2017-04-28 18:40:22 +03:00
# See also tests/vmcheck/overlay.sh
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon
2017-04-28 19:29:25 +03:00
ci: Use FAHC for build container Conceptually: we're going to move rpm-ostree and ostree at the same cadence most of the time; for both releases *and* for git master. The problem so far has been the latter part. Reusing FAHC for the build gets us half of the problem. The other trick I realized we can do - just pull ostree out from the build container. This avoids fetching it from the internet, and makes my workflow for hacking on both nicer - I just `sudo make install` in my build container for ostree. It's tempting to make the whole thing symmetric and require `sudo make install` for rpm-ostree and not do the insttree thing but...perhaps after. Closes: #758 Approved by: jlebon
2017-04-28 18:40:22 +03:00
install_builddeps rpm-ostree
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon
2017-04-28 19:29:25 +03:00
ci: Use FAHC for build container Conceptually: we're going to move rpm-ostree and ostree at the same cadence most of the time; for both releases *and* for git master. The problem so far has been the latter part. Reusing FAHC for the build gets us half of the problem. The other trick I realized we can do - just pull ostree out from the build container. This avoids fetching it from the internet, and makes my workflow for hacking on both nicer - I just `sudo make install` in my build container for ostree. It's tempting to make the whole thing symmetric and require `sudo make install` for rpm-ostree and not do the insttree thing but...perhaps after. Closes: #758 Approved by: jlebon
2017-04-28 18:40:22 +03:00
dnf install -y ostree{,-devel,-grub2} createrepo_c /usr/bin/jq PyYAML clang \
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon
2017-04-28 19:29:25 +03:00
libubsan libasan libtsan elfutils fuse sudo gnome-desktop-testing
# create an unprivileged user for testing
adduser testuser
ci: Use FAHC for build container Conceptually: we're going to move rpm-ostree and ostree at the same cadence most of the time; for both releases *and* for git master. The problem so far has been the latter part. Reusing FAHC for the build gets us half of the problem. The other trick I realized we can do - just pull ostree out from the build container. This avoids fetching it from the internet, and makes my workflow for hacking on both nicer - I just `sudo make install` in my build container for ostree. It's tempting to make the whole thing symmetric and require `sudo make install` for rpm-ostree and not do the insttree thing but...perhaps after. Closes: #758 Approved by: jlebon
2017-04-28 18:40:22 +03:00
rpm -q ostree{,-devel,-grub2}
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon
2017-04-28 19:29:25 +03:00
build --enable-installed-tests --enable-gtk-doc
Reference in New Issue Copy Permalink