shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2024-12-25 01:34:34 +03:00
Code Issues Projects Releases Wiki Activity
22e753176e
ostree/.papr.yml

135 lines
2.4 KiB
YAML
Raw Normal View History

add .redhat-ci.yml and .redhat-ci.Dockerfile Add a YAML file for the new Red Hat CI framework. Rather than re-installing all the build deps everytime, which takes time, I added a Dockerfile that we can wire up to the Docker Hub. For now it lives at `jlebon/ostree-tester:rhci`, but we can move it under the `projectatomic` org (or a new `ostree` org). Closes: #535 Approved by: cgwalters
2016-10-19 19:37:54 +03:00
branches:
- master
- auto
- try
ci: Make all ci tests gating for Homu See the rhci docs. Closes: #617 Approved by: jlebon
2016-12-07 00:29:39 +03:00
required: true
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
context: f25-primary
ci: Make all ci tests gating for Homu See the rhci docs. Closes: #617 Approved by: jlebon
2016-12-07 00:29:39 +03:00
add .redhat-ci.yml and .redhat-ci.Dockerfile Add a YAML file for the new Red Hat CI framework. Rather than re-installing all the build deps everytime, which takes time, I added a Dockerfile that we can wire up to the Docker Hub. For now it lives at `jlebon/ostree-tester:rhci`, but we can move it under the `projectatomic` org (or a new `ostree` org). Closes: #535 Approved by: cgwalters
2016-10-19 19:37:54 +03:00
container:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
image: registry.fedoraproject.org/fedora:25
ci: Combine UBSAN and ASAN by default I only recently realized this was possible. While we're still seeing leaks in the CI environment for some reason, adding ASAN gives us use-after-free detection etc., which is obviously still very useful even if we're not doing leak checking. Closes: #622 Approved by: jlebon
2016-12-08 05:26:43 +03:00
packages:
ci: Add a check that submodule changes include "Update submodule: " To prevent repeats of https://github.com/ostreedev/ostree/pull/693 I tested this script in https://github.com/cgwalters/playground/pull/48 Closes: #770 Approved by: jlebon
2017-03-30 23:47:57 +03:00
- git
ci: Combine UBSAN and ASAN by default I only recently realized this was possible. While we're still seeing leaks in the CI environment for some reason, adding ASAN gives us use-after-free detection etc., which is obviously still very useful even if we're not doing leak checking. Closes: #622 Approved by: jlebon
2016-12-08 05:26:43 +03:00
.redhat-ci.yml: use new build key This allows us to more concisely separate building from testing, which in turn gives us a nicer inheritance pattern in our case. See also: https://github.com/jlebon/redhat-ci/issues/11 Closes: #569 Approved by: cgwalters
2016-11-09 05:37:43 +03:00
env:
ci: Enable -Werror=unused-result with -Wp,-D_FORTIFY_SOURCE=2 (Also rename the other CI contexts to be more consistent) We pass this right now. I just noticed an instance of this in bwrap, and I think we should be trying to match the RPM build baseline. Closes: #765 Approved by: jlebon
2017-03-28 20:29:38 +03:00
CFLAGS: '-fsanitize=undefined -fsanitize-undefined-trap-on-error -fsanitize=address -O2 -Wp,-D_FORTIFY_SOURCE=2'
ci: Combine UBSAN and ASAN by default I only recently realized this was possible. While we're still seeing leaks in the CI environment for some reason, adding ASAN gives us use-after-free detection etc., which is obviously still very useful even if we're not doing leak checking. Closes: #622 Approved by: jlebon
2016-12-08 05:26:43 +03:00
ASAN_OPTIONS: 'detect_leaks=0' # Right now we're not fully clean, but this gets us use-after-free etc
# TODO when we're doing leak checks: G_SLICE: "always-malloc"
.redhat-ci.yml: use new build key This allows us to more concisely separate building from testing, which in turn gives us a nicer inheritance pattern in our case. See also: https://github.com/jlebon/redhat-ci/issues/11 Closes: #569 Approved by: cgwalters
2016-11-09 05:37:43 +03:00
add .redhat-ci.yml and .redhat-ci.Dockerfile Add a YAML file for the new Red Hat CI framework. Rather than re-installing all the build deps everytime, which takes time, I added a Dockerfile that we can wire up to the Docker Hub. For now it lives at `jlebon/ostree-tester:rhci`, but we can move it under the `projectatomic` org (or a new `ostree` org). Closes: #535 Approved by: cgwalters
2016-10-19 19:37:54 +03:00
tests:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- ci/ci-commitmessage-submodules.sh
- ci/build-check.sh
add .redhat-ci.yml and .redhat-ci.Dockerfile Add a YAML file for the new Red Hat CI framework. Rather than re-installing all the build deps everytime, which takes time, I added a Dockerfile that we can wire up to the Docker Hub. For now it lives at `jlebon/ostree-tester:rhci`, but we can move it under the `projectatomic` org (or a new `ostree` org). Closes: #535 Approved by: cgwalters
2016-10-19 19:37:54 +03:00
timeout: 30m
artifacts:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- test-suite.log
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
---
ci: Add CentOS 7 build For similar reasons as https://github.com/projectatomic/rpm-ostree/pull/824 Closes: #919 Approved by: jlebon
2017-06-09 17:57:40 +03:00
context: c7-build
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
inherit: true
ci: Add CentOS 7 build For similar reasons as https://github.com/projectatomic/rpm-ostree/pull/824 Closes: #919 Approved by: jlebon
2017-06-09 17:57:40 +03:00
required: true
container:
image: registry.centos.org/centos/centos:7
env:
CFLAGS: ''
tests:
- ci/build-check.sh
---
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
context: f25-rust
ci: Add CentOS 7 build For similar reasons as https://github.com/projectatomic/rpm-ostree/pull/824 Closes: #919 Approved by: jlebon
2017-06-09 17:57:40 +03:00
inherit: true
container:
image: registry.fedoraproject.org/fedora:25
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
packages:
- cargo
env:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
CONFIGOPTS: '--enable-rust'
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
tests:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- ci/build.sh
oxidation: Add implementation of bupsplit in Rust This is an initial drop of "oxidation", or adding implementation of components in Rust. The bupsplit code is a good target - no dependencies, just computation. Translation into Rust had a few twists - - The C code relies a lot on overflowing unsigned ints, and also on the C promotion rules for e.g. `uint8_t -> int32_t` - There were some odd loops that I introduced bugs in while translating...in particular, the function always returns `len`, but I mistakenly translated to `len+1`, resulting in an OOB read on the C side, which was hard to debug. On the plus side, an off-by-one array indexing in the Rust code paniced nicely. In practice, we'll need a lot more build infrastructure to make this work, such as using `cargo vendor` when producing build artifacts for example. Also, Cargo is yet another thing we need to cache. Where do we go with this? Well, I think we should merge this, it's not a lot of code. We can just have it be an alternative CI target. Should we do a lot more right now? Probably not immediately, but I find the medium/long term prospects pretty exciting! Closes: #656 Approved by: jlebon
2017-01-25 05:43:53 +03:00
- make check TESTS=tests/test-rollsum
ci: Add unit case for --enable-experimental-api We're starting to get a lot of contexts, and this is likely going to drive some requirements for consolidation and improvements like not testing *every* context on every PR, etc. But for now since experimental is new, and under development, let's test it. Closes: #875 Approved by: cgwalters
2017-05-19 17:39:48 +03:00
---
inherit: true
context: f25-experimental-api
env:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
CONFIGOPTS: '--enable-experimental-api'
ci: Add unit case for --enable-experimental-api We're starting to get a lot of contexts, and this is likely going to drive some requirements for consolidation and improvements like not testing *every* context on every PR, etc. But for now since experimental is new, and under development, let's test it. Closes: #875 Approved by: cgwalters
2017-05-19 17:39:48 +03:00
tests:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- ci/build-check.sh
ci: Add unit case for --enable-experimental-api We're starting to get a lot of contexts, and this is likely going to drive some requirements for consolidation and improvements like not testing *every* context on every PR, etc. But for now since experimental is new, and under development, let's test it. Closes: #875 Approved by: cgwalters
2017-05-19 17:39:48 +03:00
libcurl backend For rpm-ostree, we already link to libcurl indirectly via librepo, and only having one HTTP library in process makes sense. Further, libcurl is (I think) more popular in the embedded space. It also supports HTTP/2.0 today, which is a *very* nice to have for OSTree. This seems to be working fairly well for me in my local testing, but it's obviously brand new nontrivial code, so it's going to need some soak time. The ugliest part of this is having to vendor in the soup-url code. With Oxidation we could follow the path of Firefox and use the [Servo URL parser](https://github.com/servo/rust-url). Having to redo cookie parsing also sucked, and that would also be a good oxidation target. But that's for the future. Closes: #641 Approved by: jlebon
2016-12-08 05:02:30 +03:00
---
inherit: true
required: true
ci: Enable -Werror=unused-result with -Wp,-D_FORTIFY_SOURCE=2 (Also rename the other CI contexts to be more consistent) We pass this right now. I just noticed an instance of this in bwrap, and I think we should be trying to match the RPM build baseline. Closes: #765 Approved by: jlebon
2017-03-28 20:29:38 +03:00
context: f25-curl-openssl
libcurl backend For rpm-ostree, we already link to libcurl indirectly via librepo, and only having one HTTP library in process makes sense. Further, libcurl is (I think) more popular in the embedded space. It also supports HTTP/2.0 today, which is a *very* nice to have for OSTree. This seems to be working fairly well for me in my local testing, but it's obviously brand new nontrivial code, so it's going to need some soak time. The ugliest part of this is having to vendor in the soup-url code. With Oxidation we could follow the path of Firefox and use the [Servo URL parser](https://github.com/servo/rust-url). Having to redo cookie parsing also sucked, and that would also be a good oxidation target. But that's for the future. Closes: #641 Approved by: jlebon
2016-12-08 05:02:30 +03:00
packages:
- pkgconfig(libcurl)
core: Support building with OpenSSL for checksums Add an OpenSSL backend to the checksum input stream, which is where we do a lot of checksumming (object commit, static deltas). The raw OpenSSL performance is [approximately double](https://gist.github.com/cgwalters/169349fd1c06fd4fb4d3a7ce33303222) on my laptop; not only does OpenSSL have e.g. hand-tuned x86_64 assembly, the current implementation uses the [Intel SHA extensions](https://en.wikipedia.org/wiki/Intel_SHA_extensions). Another reason to do this is I was idly thinking about adding [Curve25519](https://en.wikipedia.org/wiki/Curve25519) signatures (like e.g. Alpine does) instead of/in addition to GPG. The rationale for that is that GPG is pretty heavyweight, both in code footprint and the simple fact that EC keys are way smaller. I didn't benchmark ostree with this; we have bigger performance problems really like the fact we just malloc way too much. But, it's a step in the right direction I think in combination with the libcurl work where we're linking to openssl anyways. Closes: #738 Approved by: jlebon
2017-03-13 21:41:14 +03:00
- pkgconfig(openssl)
libcurl backend For rpm-ostree, we already link to libcurl indirectly via librepo, and only having one HTTP library in process makes sense. Further, libcurl is (I think) more popular in the embedded space. It also supports HTTP/2.0 today, which is a *very* nice to have for OSTree. This seems to be working fairly well for me in my local testing, but it's obviously brand new nontrivial code, so it's going to need some soak time. The ugliest part of this is having to vendor in the soup-url code. With Oxidation we could follow the path of Firefox and use the [Servo URL parser](https://github.com/servo/rust-url). Having to redo cookie parsing also sucked, and that would also be a good oxidation target. But that's for the future. Closes: #641 Approved by: jlebon
2016-12-08 05:02:30 +03:00
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
env:
CONFIGOPTS: "--with-curl --with-openssl"
libcurl backend For rpm-ostree, we already link to libcurl indirectly via librepo, and only having one HTTP library in process makes sense. Further, libcurl is (I think) more popular in the embedded space. It also supports HTTP/2.0 today, which is a *very* nice to have for OSTree. This seems to be working fairly well for me in my local testing, but it's obviously brand new nontrivial code, so it's going to need some soak time. The ugliest part of this is having to vendor in the soup-url code. With Oxidation we could follow the path of Firefox and use the [Servo URL parser](https://github.com/servo/rust-url). Having to redo cookie parsing also sucked, and that would also be a good oxidation target. But that's for the future. Closes: #641 Approved by: jlebon
2016-12-08 05:02:30 +03:00
tests:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- ci/build-check.sh
tests/installed: New installed, privileged tests using Fedora AH Our container-driven tests can't e.g. test SELinux sanely, and have to support being run as root *and* non-root too. Use redhat-ci to provision a VM and run tests directly there. These are installed tests too. Closes: https://github.com/ostreedev/ostree/issues/806 Closes: #807 Approved by: jlebon
2017-04-24 21:40:06 +03:00
---
inherit: false
branches:
- master
- auto
- try
context: f25ah-insttest
required: false
cluster:
hosts:
- name: vmcheck
distro: fedora/25/atomic
container:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
image: registry.fedoraproject.org/fedora:25
tests/installed: New installed, privileged tests using Fedora AH Our container-driven tests can't e.g. test SELinux sanely, and have to support being run as root *and* non-root too. Use redhat-ci to provision a VM and run tests directly there. These are installed tests too. Closes: https://github.com/ostreedev/ostree/issues/806 Closes: #807 Approved by: jlebon
2017-04-24 21:40:06 +03:00
# Copy the build from the container to the host; ideally down the line
# this is installing an RPM via https://github.com/jlebon/redhat-ci/issues/10
tests:
ci: Update to match current rpm-ostree This copies the `ci/` directory from rpm-ostree, with much the same rationale; among other things we don't want to depend on the Docker hub. The specific reason I'm doing this is that I want to add a CentOS7 build, but that means we can't use `projectatomic/ostree-tester`, and at that point we might as well unwind it all. Closes: #917 Approved by: jlebon
2017-06-08 20:47:20 +03:00
- ci/build.sh
tests/installed: New installed, privileged tests using Fedora AH Our container-driven tests can't e.g. test SELinux sanely, and have to support being run as root *and* non-root too. Use redhat-ci to provision a VM and run tests directly there. These are installed tests too. Closes: https://github.com/ostreedev/ostree/issues/806 Closes: #807 Approved by: jlebon
2017-04-24 21:40:06 +03:00
- make install DESTDIR=$(pwd)/insttree
- rsync -rl -e 'ssh -o User=root' . vmcheck:ostree/
ci: Extend FAH rootfs for installed tests These at the moment aren't in a container, and may need space. In the future overlay2 will help here, we can more easily extend the rootfs. Closes: #840 Approved by: jlebon
2017-05-08 23:44:42 +03:00
- ssh root@vmcheck './ostree/tests/installed/fah-prep.sh && ostree admin unlock && rsync -rlv ./ostree/insttree/usr/ /usr/ && ./ostree/tests/installed/run.sh'
tests/installed: New installed, privileged tests using Fedora AH Our container-driven tests can't e.g. test SELinux sanely, and have to support being run as root *and* non-root too. Use redhat-ci to provision a VM and run tests directly there. These are installed tests too. Closes: https://github.com/ostreedev/ostree/issues/806 Closes: #807 Approved by: jlebon
2017-04-24 21:40:06 +03:00
ci: Add a context for testing flatpak This was part of the philosophy behind https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests - libraries like libostree don't need to replicate everything in unit tests, we can use the tests from our dependencies directly too. We'll also get API break coverage testing too. Closes: #818 Approved by: jlebon
2017-04-28 16:32:35 +03:00
---
inherit: false
branches:
- master
- auto
- try
context: f25-flatpak
required: false
# This test case wants an "unprivileged container with bubblewrap",
# which we don't have right now; so just provision a VM and do a
# docker --privileged run.
host:
distro: fedora/25/atomic
ci: More flatpak ci fixes We need our `make install` to override the ostree RPM, so do it all in one txn. This sort of thing is where a more rigorous model like rdgo/gcontinuous use becomes better, but we'll hack it with shell for now. Closes: #824 Approved by: jlebon
2017-05-02 01:02:27 +03:00
specs:
ram: 4096 # build-bundle is a static delta, which needs RAM right now
ci: Add a context for testing flatpak This was part of the philosophy behind https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests - libraries like libostree don't need to replicate everything in unit tests, we can use the tests from our dependencies directly too. We'll also get API break coverage testing too. Closes: #818 Approved by: jlebon
2017-04-28 16:32:35 +03:00
tests:
- docker run --rm --privileged -v $(pwd):/srv/code registry.fedoraproject.org/fedora:25 /bin/sh -c "cd /srv/code && ./ci/flatpak.sh"
artifacts:
- test-suite.log
Reference in New Issue Copy Permalink