Use beakerlib library from current repository / metadata tree
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.
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
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.
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.
As @sopos mentioned the library should be found using the upward directory traversal. @ep69, could you confirm this does not work for you?
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?
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.
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:
- in internal company network, downloading the library (e.g.,
distribution/fips) from default place where it is stored - in public environment, having the libraries pre-downloaded in
/libsin 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.
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)
If the library Is in the same repo why adding it to requires?
@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
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).
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
@kkaarreell @sopos any idea folks?
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.
Another duplicate issues found, let's bring more attention to this. Raising the priority.