fedora-ci / general

#20 local repository should be enable for rawhide tests
Closed by bgoncalv. Opened by tstellar.

Closed
Reopen Issue

Tests for rawhide packages may have dependencies on packages in the "local" repository e.g. https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ that are not in the compose yet, so this repository should be enabled when running the tests.

As an example: clang-7.0.1 depends on llvm-7.0.1. Both packages have been built for rawhide, but there has not been a successful compose with them yet. The latest compose contains clang-7.0.0 and llvm-7.0.0. When I create a PR for clang, the CI tests fail because the system is building and installing clang-7.0.1, but it's dependency llvm-7.0.1 is not available.

Here is the RPM log from the failed test: https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/675/artifact/nvr-verify/logs/installed_rpms.txt

We've been hit by this as well. Our Python smoke tests run against old pip because the compose is so old.

Please?

Can you confirm this is still a valid issue? I believe this is already fixed.

https://github.com/CentOS-PaaS-SIG/ci-pipeline/blob/master/config/Dockerfiles/cloud-image-compose/virt-customize.sh#L94

Let's see - https://src.fedoraproject.org/rpms/python-tox/pull-request/11

hmm, okay for situation like the PR above it seems we need to drop priority=999 from this repo.

I'll provide a fix for it soon.

+1, thanks Bruno, we did not realize this while adding the first patch ...

I've removed the priority from the repo, but note for the case of python3 from python-tox PR. As python3 is already installed it will no try to update it, it will continue to use the installed version (3.7.3-3.fc31). If python3-tox would require a new version than then it would get the new version from latest repo.
Edited by bgoncalv

We want to test it in what's newest. Should we run dnf update somewhere?

Think in this case it is something that should be done on test case side. If you run dnf update for the packages we want be sure are the latest, it should work. But note you will be using packages that are not officially released.

That's the point of testing. Is there an ansible directive I should use?

@churchyard I would just run that via command ansible task ...

Ive found this: https://docs.ansible.com/ansible/2.8/modules/command_module.html

However I have no idea to what part of tests.yaml I stick that in :(

@churchyard It should be simple as:

---
- hosts: localhost
  tags:
    - classic
  tasks:
    - command: dnf -y update python3
- hosts: localhost
  roles:
  - role: standard-test-basic
    tags:
    - classic
    repositories:
    - repo: "https://src.fedoraproject.org/tests/python.git"
      dest: "python"
    tests:
    - smoke27:
        dir: python/smoke
        run: VERSION=2.7 METHOD=virtualenv ./venv.sh
    - smoke34:
        dir: python/smoke
        run: VERSION=3.4 ./venv.sh
    - smoke35:
        dir: python/smoke
        run: VERSION=3.5 ./venv.sh
    - smoke36:
        dir: python/smoke
        run: VERSION=3.6 ./venv.sh
    - smoke37:
        dir: python/smoke
        run: VERSION=3.7 ./venv.sh
    - smoke38:
        dir: python/smoke
        run: VERSION=3.8 ./venv.sh
    required_packages:
    - gcc
    - virtualenv
    - python27
    - python34
    - python35
    - python36
    - python37
    - python38
    - python2-devel
    - python3-devel
    - python3-tox

https://src.fedoraproject.org/tests/python/pull-request/9

fingers crossed 

[2019-06-26T16:23:47.784Z] TASK [command] *****************************************************************
[2019-06-26T16:26:39.200Z]  [WARNING]: Consider using the dnf module rather than running dnf.  If you need
[2019-06-26T16:26:39.200Z] to use command because dnf is insufficient you can add warn=False to this
[2019-06-26T16:26:39.200Z] command task or set command_warnings=False in ansible.cfg to get rid of this
[2019-06-26T16:26:39.200Z] message.

@churchyard that is a warning that you can safely ignore or add `warn: False to the task to silence it ...

In the referenced run the findleaks37 test failed ...

https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/1623/artifact/package-tests/logs/FAIL-str_findleaks37.log
https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/1623/artifact/package-tests/logs/FAIL-str_findleaks37-err.log

I'll try to use the dnf directive.

The findleaks test failure is known: https://bugzilla.redhat.com/show_bug.cgi?id=1677584

It works: https://src.fedoraproject.org/tests/python/c/f5948a878cf5658ffe629f54f0a808b624e59a5a?branch=master

So we want to document that somewhere? And where?

What about something like this?
https://pagure.io/fedora-ci/docs/pull-request/33

thanks @psss. I'm closing this and it has been documented on https://docs.fedoraproject.org/en-US/ci/tests/

Metadata Update from @bgoncalv:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.