tmt icon indicating copy to clipboard operation
tmt copied to clipboard

Use beakerlib library from current repository / metadata tree

Open ep69 opened this issue 4 years ago • 14 comments

As a tester writing the test that needs beakerlib library from the same repository, I want to be able to use that library without specifying URL of the repository, so that the URL information is not duplicated and the whole repository is more maintainable & migratable.

From the discussion we had with @psss, the first step is to have url part of FMF id default to the same repository as the current test. Also, as brought up by @kkaarreell, new convention or specific agreement for rlImport arguments might be needed.

ep69 avatar Feb 01 '21 15:02 ep69

We use rlImport ./ica for our library but this approach won't ensure that library requires are installed. https://gitlab.cee.redhat.com/rhel-tests/openssl-ibmca/-/blob/main/integration/mod_ssl-using-ibmca-hw-acceleration/test.sh#L20

kkaarreell avatar Mar 09 '23 10:03 kkaarreell

FTR: Either 'url' or 'path' is currently required when processing requires. We had defined 'fmf-id' that when url is missing it should be the current repo - thus omitting 'url' should lead to the desired "detect library from the current tree" situation.

lukaszachy avatar Mar 09 '23 10:03 lukaszachy

I think it should work even with the file type require. That should ensure the respective file is synced to guest. Beakerlib should be already capable to handle a require defined by the name only, possibly with path as well; so rlImport --all or a dependent requires should be handled correctly.

sopos avatar May 16 '23 10:05 sopos

As @sopos mentioned the library should be found using the upward directory traversal. @ep69, could you confirm this does not work for you?

psss avatar Jun 20 '23 08:06 psss

What exact scenario are we discussing? rlImport fips / rlImport distribution/fips / rlImport crypto/fips + require: library(<same>) in main.fmf? What is expected to work and what not?

ep69 avatar Jun 21 '23 08:06 ep69

All should work if you have the following directory structure in the repo: [/libs]/fips [/libs]/distribution/fips [/libs]/crypto/fips

Except for the require: library(...). which would make tmt to try to install it which would fail. For that you would need to use the new type: file require.

sopos avatar Jun 23 '23 09:06 sopos

This is not a high priority as I am able to workaround it, but it does not seem to be working for my case.

I was mostly looking for a way to have same test script and metadata running in two environments:

  1. in internal company network, downloading the library (e.g., distribution/fips) from default place where it is stored
  2. in public environment, having the libraries pre-downloaded in /libs in current repo

Is something like this possible? If so, cool, I can get rid of my workarounds and rewrites. If not, I can go on with my life, too.

ep69 avatar Sep 08 '23 14:09 ep69

Btw, specifying library without url:, just with path:, somehow does not work for me:

require:
  - type: library
    path: /libs/distribution
    name: /fips

gives me:

# tmt run -avvv plans -n interop tests -f "tag:interop-gnutls" provision -h local execute -h tmt --interactive test -n /Interoperability/gnutls_TLSv1-2-with-OpenSSL
/var/tmp/tmt/run-010
Found 1 plan.

/plans/interop
summary: Upstream interoperability
    discover
        how: fmf
        order: 50
        directory: /root/interop
        hash: 3def3aa
        filter: tag: interop
    finish
    
    Prune '/plans/interop' plan workdir '/var/tmp/tmt/run-010/plans/interop'.
        summary: 0 tasks completed

plan failed

The exception was caused by 1 earlier exceptions

Cause number 1:

    unhashable type: 'DependencyFmfId'

# tmt --version
tmt version: 1.26.1 (514544b2)

ep69 avatar Sep 08 '23 14:09 ep69

If the library Is in the same repo why adding it to requires?

kkaarreell avatar Sep 08 '23 14:09 kkaarreell

@ep69 Can you revisit this? We are unclear what is the issue here to fix, seems @sopos and @kkaarreell seems no to be able to confirm the problem. If you do not reply we will close this issue. Thank you

thrix avatar Mar 18 '25 10:03 thrix

Actually, specifying the library without url in the same repo makes perfect sense as it is explicit rather than implicit, it is forward compatible even for data transfer optimization (upload only really needed stuff).

sopos avatar Mar 18 '25 16:03 sopos

I still don't seem to be able to specify tmt require: from the same repository.

Structure of the repo: (available in https://gitlab.com/redhat-crypto/tests/interop/-/tree/cleanup-libpaths?ref_type=heads/)

.
├── Interoperability
...
│   ├── openssl_tls-1-3-interoperability-gnutls-openssl-2way
...
├── libs
│   ├── distribution
│   │   └── fips
...
│   └── openssl
│       ├── certgen
│       ├── tls-1-3-interoperability-gnutls-openssl
...
└── plans

Requires specified like this:

require:
  - {'type': 'library', 'path': '/libs/openssl', 'name': '/certgen'}
  - {'type': 'library', 'path': '/libs/distribution', 'name': '/fips'}
  - {'type': 'library', 'path': '/libs/openssl', 'name': '/tls-1-3-interoperability-gnutls-openssl'}

Command: tmt run -a plans -n interop tests -f "tag:interop-gnutls" -f "tag:interop-2way" -f "tag:interop-openssl" provision -h local --feeling-safe execute -h tmt --interactive

Running it in container used in gnutls upstream ci: podman run -it registry.gitlab.com/gnutls/build-images:buildenv-fedora41 (clone previously mentioned repo, using branch cleanup-libpaths, cd into it and run tmt command)

Should I do something differently?

EDIT: I guess the output might be handy, right?

/var/tmp/tmt/run-001

/plans/interop
    discover
        how: fmf
        directory: /interop
        filter: tag:interop-gnutls
        filter: tag:interop-2way
        filter: tag:interop-openssl
        summary: 1 test selected
    provision
        queued provision.provision task #1: default-0
        
        provision.provision task #1: default-0
        how: local
        primary address: localhost
        multihost name: default-0
        arch: x86_64
        distro: Fedora Linux 41 (Container Image)
    
        summary: 1 guest provisioned
    prepare
    fail: Invalid requirement: DependencyFmfId(fmf_root=None, git_root=None, default_branch=None, url=None, ref=None, path=Path('/libs/openssl'), name='/certgen', destination=None, nick=None, type='library')
    fail: Invalid requirement: DependencyFmfId(fmf_root=None, git_root=None, default_branch=None, url=None, ref=None, path=Path('/libs/distribution'), name='/fips', destination=None, nick=None, type='library')
    fail: Invalid requirement: DependencyFmfId(fmf_root=None, git_root=None, default_branch=None, url=None, ref=None, path=Path('/libs/openssl'), name='/tls-1-3-interoperability-gnutls-openssl', destination=None, nick=None, type='library')
    report
        how: display
        summary: 1 pending
    finish
    
        summary: 0 tasks completed

plan failed

The exception was caused by 1 earlier exceptions

Cause number 1:

    After beakerlib processing, tests may have only simple requirements

ep69 avatar Apr 01 '25 13:04 ep69

@kkaarreell @sopos any idea folks?

thrix avatar Apr 01 '25 23:04 thrix

According to https://github.com/teemtee/tmt/issues/522#issuecomment-2769406130, there is something left to investigate, tmt should replace library-ish requirements with simple ones, packages and/or paths, and libraries should not remain in the mix. That needs to be debugged first. Adding to backlog so someone could dive in.

happz avatar Apr 22 '25 09:04 happz

Another duplicate issues found, let's bring more attention to this. Raising the priority.

psss avatar Oct 01 '25 10:10 psss