shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2025-01-12 13:18:27 +03:00
Code Issues Projects Releases Wiki Activity
c2f5a999bf
ostree/.redhat-ci.yml

98 lines
1.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
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:
.redhat-ci.yml: use projectatomic/ostree-tester Same Dockerfile, but automated to rebuild on pushes. Closes: #536 Approved by: giuseppe
2016-10-19 23:49:56 +03:00
image: projectatomic/ostree-tester
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
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:
- libasan
.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: Hard error on all -fsanitize=undefined warnings I saw in a recent test log a ton of spam ``` libglnx/glnx-dirfd.c:253:3: runtime error: null pointer passed as argument 1, which is declared to never be null ``` which actually turned out to be libglnx getting reverted. But let's be sure now we actually bomb out quickly on UBSAN warnings in general. Closes: #693 Approved by: jlebon
2017-02-18 00:59:21 +03:00
CFLAGS: '-fsanitize=undefined -fsanitize-undefined-trap-on-error -fsanitize=address'
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
build:
config-opts: >
--prefix=/usr
--libdir=/usr/lib64
--enable-installed-tests
--enable-gtk-doc
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:
- make syntax-check
- make check
ci: Drop sudo installed tests This conflicts with the ASAN work...and in general, I think I'd like to make a new format for tests that require root, and have them be defined to be in mutable containers or VMs. Our coverage loss from this isn't much because some of these tests already required `CAP_SYS_ADMIN` which we didn't have in Docker anyways. While we have the patient open, parallelize the regular installed tests. Closes: #622 Approved by: jlebon
2016-12-08 21:35:29 +03:00
- gnome-desktop-testing-runner -p 0 ostree
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:
- test-suite.log
.redhat-ci.yml: add clang Clang has better detection for unused vars when using auto cleanup functions. We should eventually just fold this back into the first testsuite. But let's just turn it on for now, at least until it's satisfied with the whole codebase. Closes: #549 Approved by: cgwalters
2016-10-27 19:03:04 +03:00
---
inherit: true
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
.redhat-ci.yml: add clang Clang has better detection for unused vars when using auto cleanup functions. We should eventually just fold this back into the first testsuite. But let's just turn it on for now, at least until it's satisfied with the whole codebase. Closes: #549 Approved by: cgwalters
2016-10-27 19:03:04 +03:00
context: Clang
.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:
CC: 'clang'
CFLAGS: '-Werror=unused-variable'
tests:
.redhat-ci.yml: add clang Clang has better detection for unused vars when using auto cleanup functions. We should eventually just fold this back into the first testsuite. But let's just turn it on for now, at least until it's satisfied with the whole codebase. Closes: #549 Approved by: cgwalters
2016-10-27 19:03:04 +03:00
artifacts:
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
context: f25-rust
packages:
- cargo
build:
config-opts: >
--prefix=/usr
--libdir=/usr/lib64
--enable-installed-tests
--enable-gtk-doc
--enable-rust
env:
CC: 'gcc'
tests:
- make check TESTS=tests/test-rollsum
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
context: curl
packages:
- pkgconfig(libcurl)
build:
config-opts: >
--prefix=/usr
--libdir=/usr/lib64
--enable-installed-tests
--enable-gtk-doc
--with-curl
tests:
- make check
- gnome-desktop-testing-runner -p 0 ostree
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
artifacts:
- test-suite.log
Reference in New Issue Copy Permalink