CI March 2018

ci@lists.fedoraproject.org

9 participants
4 discussions

Reworking ostree's upstream CI to use the STI
by Colin Walters 20 Apr '18

20 Apr '18

https://github.com/ostreedev/ostree/pull/1462 Some things I like specifically: - The qcow2 inventory is useful (though I want it to be more configurable) - Ansible is mostly better than shell script - It's a layer of stuff that's abstract across "execution environments" like Jenkins vs whatever else - The concept that playbooks can in theory be more easily shared And of course that it makes things a bit more obvious how to reuse *upstream* tests stored in upstream git in the downstream dist-git (though I need to actually plumb that through). BTW we're also in the process of completely revamping our "CI execution" or https://github.com/projectatomic/papr to use Kubernetes/OpenShift more. In our case then the upstream tests using STI would actually execute as Kubernetes Jobs; in our particular case then we'd be moving strongly towards VM-in-container. See: https://github.com/projectatomic/papr/pull/70 https://github.com/projectatomic/paci/pulls?q=is%3Apr+is%3Aclosed etc.; also part of this is moving our CI into CentOS CI's OpenShift instance.

1 1

Is gating on dist-git tests working in Fedora?
by Stef Walter 12 Apr '18

12 Apr '18

Hi there, Is the CI pipeline running on Fedora and gating? It's really hard to find test results. I'm looking around both in Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2018-5c64b23a18 and here Pagure: https://src.fedoraproject.org/rpms/cockpit/pull-request/3 The Cockpit Git repository has a "test-canary" test that checks whether CI gates on test failure. Here's what you see when you run the tests in dist-git locally: TASK [standard-test-scripts : Check the results] ******************************* fatal: [localhost]: FAILED! => {"changed": true, "cmd": "grep \"^FAIL\" /var/tmp/artifacts/test.log", "delta": "0:00:00.002181", "end": "2018-03-26 14:04:10.414274", "failed_when_result": true, "rc": 0, "start": "2018-03-26 14:04:10.412093", "stderr": "", "stderr_lines": [], "stdout": "FAIL ./test-canary", "stdout_lines": ["FAIL ./test-canary"]} /tests.retry Cheers, Stef

8 24

Local testing & test development - Ansible & Mock
by Michal Schorm 14 Mar '18

14 Mar '18

Hi folks, Is there any automatized way to run the tests localy in Mock? So far I've seen 2 options: direct invoke "# ansible-playbook tests.yml" or runing VM from downloaded qcow2 image Certain tests could break my system so I'd like to not running them in somehow isolated environment. Also, I'd use some safe way to develop such tests. Which will lead to broken system much more likely. -- Should I expect this idea incorporated, or should I rather prepare some VMs? (lesser size tan 600MB each image) -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

4 3

Ouptut for beakerlib tests
by Tim Flink 06 Mar '18

06 Mar '18

There's a bug currently open for the standard test roles where there are duplicate output lines in the logfile output when the beakerlib role is complete. https://pagure.io/standard-test-roles/issue/83 The summary of the issue is this: beakerlib outputs to stdout, stderr and a logfile which do have some duplicate information between them but none of them are identical. As a reference to what other beakerlib environments do, Beaker seems to put all three into separate files. What do we want to have as the primary output of the beakerlib role? My instinct is to use the logfile as the primary output because it is the easiest to scan, even if it is lacking details. STDOUT and STDERR could then be combined into a second file or kept separate yet still included in the artifacts generated. Any thoughts on this plan or another method for getting duplicated lines out of the log output? Thanks, Tim

2 1

2024

2023

2022

2021

2020

2019

2018

2017

CI March 2018