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

32 lines
1.2 KiB
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
ci: unite testsuites and run vmcheck on centos We can be a bit less wasteful here by merging the check and vmcheck suites into a single suite. The check suite today takes a negligible amount of time to run, so we're not gaining much by parallelizing them. It's more of a sanity check at this point before we start vmcheck. Also start running vmcheck on CentOS 7. We adapt the ci scripts to accomodate both Fedora and CentOS target machines. This commit also switches to Fedora 26 as the primary test base. Closes: #871 Approved by: cgwalters
2017-07-17 20:40:25 +03:00
id=$(. /etc/os-release && echo $ID)
version_id=$(. /etc/os-release && echo $VERSION_ID)
if [ "$id" == fedora ] && [ "$version_id" == 26 ]; then
echo -e '[fahc]\nbaseurl=https://ci.centos.org/artifacts/sig-atomic/fahc/rdgo/build/\ngpgcheck=0\n' > /etc/yum.repos.d/fahc.repo
# 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
elif [ "$id" == centos ]; then
echo -e '[cahc]\nbaseurl=https://ci.centos.org/artifacts/sig-atomic/rdgo/centos-continuous/build\ngpgcheck=0\n' > /etc/yum.repos.d/cahc.repo
fi
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
lib: Expose new API around basearch For https://pagure.io/atomic-wg/issue/299 we need to make it more convenient to substitute the architecture in an installation context. I plan to use this API inside `rpmostreepayload` in Anaconda, so we can substitute the same value of `${basearch}` we use in treefiles since https://github.com/projectatomic/rpm-ostree/pull/305 Now, you might wonder - why do we need an API wrapping libdnf? It's because libdnf is not API stable yet. We're just exposing a tiny subset. In theory we could use the Python dnf bindings in Anaconda, but things get slightly weird if rpmostreepayload depends on dnf. Perhaps we'll do that down the road, but for now this a small API surface to maintain (forever). This change reworks the internal `varsubst` bits to take a pure `DnfContext`, since we don't want to spin up a whole `RpmOstreeContext` just to do some string substitutions. Closes: #877 Approved by: jlebon
2017-07-13 23:39:01 +03:00
yum install -y /usr/bin/g-ir-scanner # Accidentally omitted
# Mostly dependencies for tests
ci: unite testsuites and run vmcheck on centos We can be a bit less wasteful here by merging the check and vmcheck suites into a single suite. The check suite today takes a negligible amount of time to run, so we're not gaining much by parallelizing them. It's more of a sanity check at this point before we start vmcheck. Also start running vmcheck on CentOS 7. We adapt the ci scripts to accomodate both Fedora and CentOS target machines. This commit also switches to Fedora 26 as the primary test base. Closes: #871 Approved by: cgwalters
2017-07-17 20:40:25 +03:00
yum install -y ostree{,-devel,-grub2} createrepo_c /usr/bin/jq PyYAML clang \
lib: Expose new API around basearch For https://pagure.io/atomic-wg/issue/299 we need to make it more convenient to substitute the architecture in an installation context. I plan to use this API inside `rpmostreepayload` in Anaconda, so we can substitute the same value of `${basearch}` we use in treefiles since https://github.com/projectatomic/rpm-ostree/pull/305 Now, you might wonder - why do we need an API wrapping libdnf? It's because libdnf is not API stable yet. We're just exposing a tiny subset. In theory we could use the Python dnf bindings in Anaconda, but things get slightly weird if rpmostreepayload depends on dnf. Perhaps we'll do that down the road, but for now this a small API surface to maintain (forever). This change reworks the internal `varsubst` bits to take a pure `DnfContext`, since we don't want to spin up a whole `RpmOstreeContext` just to do some string substitutions. Closes: #877 Approved by: jlebon
2017-07-13 23:39:01 +03:00
libubsan libasan libtsan elfutils fuse sudo python-gobject-base
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
# 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