#182 WIP: Add cockpit-podman reverse dependency gating test
Closed 10 months ago by martinpitt. Opened 11 months ago by martinpitt.
rpms/ martinpitt/cockpit f38  into  f38

file modified
+2 -1
@@ -3,7 +3,8 @@ 

    - fedora-*

  decision_context: bodhi_update_push_stable

  rules:

-   - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}

+   - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build./plans/cockpit.functional}

+   - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build./plans/cockpit-podman.functional}

  

  --- !Policy

  product_versions:

@@ -0,0 +1,21 @@ 

+ discover:

+     how: fmf

+     url: https://src.fedoraproject.org/rpms/cockpit-podman

+     dist-git-source: true

+ execute:

+     how: tmt

+ 

+ /system:

+     summary: Run tests on system podman

+     discover+:

+         test: /test/browser/system

+ 

+ /user:

+     summary: Run tests on user podman

+     discover+:

+         test: /test/browser/user

+ 

+ /misc:

+     summary: Run other tests

+     discover+:

+         test: /test/browser/other

plans/cockpit.fmf plans/all.fmf
file renamed
file was moved with no change to the file

Add a test plan for cockpit-podman, and enable multi-plan gating [1].

Rename "all" plan to "cockpit" for clarity.

[1] https://docs.fedoraproject.org/en-US/ci/gating/#_using_multiple_plans

This first approach is obviously nonsense, as the cockpit-podman.fmf plan does not point to the actual cockpit-podman dist-git, so dist-git-source will be lost

However, when I would move to url: https://src.fedoraproject.org/rpms/cockpit-podman, it would once again also need a corresponding ref:, which cannot be computed dynamically. At most, it could point to rawhide or f38 etc., but dist-git is almost always out of sync with what's actually available via dnf install in Fedora, due to the long waiting times in updates-proposed and mirror delays. So this runs into more or less the same issue as my upstream experiments.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/693495ba0abc451d86884737dbcbc1d8

@ksrot perhaps you have some idea how this could work? You pointed me to https://src.fedoraproject.org/rpms/tpm2-tools/blob/rawhide/f/ci.fmf the other day, but that doesn't really test another dist-git package, but some standalone https://github.com/RedHat-SP-Security/keylime-tests repo which is made for running against different package versions. This is not generally the case for dist-git tests, which usually co-evolve with the upstream code, and thus the test and the code must run from the same commit (that's why dist-git-source: true is so incredibly useful).

I also scheduled a meeting for this, but it may be useful to collect some initial info for that. Thanks!

1 new commit added

  • Test; Add cockpit-podman URL to test plan
11 months ago

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/3a0b4962b08f432985d60b040a1a48ac

Yep, as expected url plus dist-git-source does not work either. As ref: cannot be determined dynamically (and that's not a tmt issue, dist-git just isn't organized that way), I don't currently see a solution.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/ff678f1dc21d4f88a9434de807580abc

@ksrot perhaps you have some idea how this could work? You pointed me to https://src.fedoraproject.org/rpms/tpm2-tools/blob/rawhide/f/ci.fmf the other day, but that doesn't really test another dist-git package, but some standalone https://github.com/RedHat-SP-Security/keylime-tests repo which is made for running against different package versions. This is not generally the case for dist-git tests, which usually co-evolve with the upstream code, and thus the test and the code must run from the same commit (that's why dist-git-source: true is so incredibly useful).

You are right. However, that standalone test repo is in fact our attempt to bypass limitations we would be facing when running keylime tests from multiple projects while maintaining tests themself as a part one the keylime repo itself.

Yep, as expected url plus dist-git-source does not work either. As ref: cannot be determined dynamically (and that's not a tmt issue, dist-git just isn't organized that way), I don't currently see a solution.

ref: can be determined dynamically, I am just not sure it would work for your set up.
See https://tmt.readthedocs.io/en/stable/examples.html#dynamic-ref-evaluation

Right, I saw that tmt doc already, but that's not the main problem -- there's just no way to map the current Fedora version to a dist-git commit :cry:

Pull-Request has been closed by martinpitt

10 months ago