Easier dependencies handling for packages, e.g. reduce duplication of build requirements in spec, documentation, Dockerfile
For both os-autoinst and openQA "build requirements" are defined in multiple places, e.g. https://github.com/os-autoinst/openQA/blob/master/docker/travis_test/Dockerfile#L10 , https://github.com/os-autoinst/openQA/blob/master/cpanfile , https://github.com/os-autoinst/openQA/blob/master/openQA.spec#L37 and correspondingly for os-autoinst . This fact and also the current setup based on the Dockerfile "docker/travis_test/Dockerfile" which a container is built from in OBS, but only after merge of a PR, makes it hard to understand and hard to introduce new dependencies and test for them properly.
#1 Updated by okurz about 2 years ago
What I thought of and partially tried:
- Define a "devel" package in the spec file and let it require all build time dependencies which are needed also for use outside OBS and install that virtual package whenever we want to develop, e.g. as in https://github.com/os-autoinst/os-autoinst/pull/1171
- Generate the spec file completely from a template and generated information, e.g. as with cpan2spec. Challenge would be where to store the spec-file. The best I could think of is to use travis CI to generate the spec file for every merge to master and save it in a special non-master git branch which the OBS service can check out. Why not store in master? A: To not mix generated and human-written files
- Extract the dependencies for the container scripts from the spec file, e.g. by parsing it and transforming into a list to give to zypper on-the-fly
All of the above help to define a single place for dependencies. Now to actually solve the problem that dependencies would only be active after merge not before one could use the same dependency list in the downstream "openqa" container (not "travis_test" aka. "openqa_dev") and call
zypper -n in $deps again to cover any potential diff in packages, e.g. when adding new dependencies.
Other thing: We have a container "travis_test" aka. "openqa_dev" which is built and published by OBS and a container "openqa" based on openqa_dev which is built and run only during travis CI tests. This is confusing (the names in particular) and not helping us to cover testing of the actual other Dockerfiles we have. Maybe we can get rid of "openqa" by building "openqa_dev" again but based on cached results? Maybe define the "openqa" container just as here-doc and a less complicated script with more setup-helper-scripts, e.g. as in https://github.com/okurz/openQA/commit/b255b05939417792580abf8d5e017c28d33d75b1 where I reduce duplication to setup a test database
EDIT: Maybe https://stackoverflow.com/questions/4339417/is-there-any-syntax-or-trick-to-be-able-to-create-a-multiline-rpm-spec-file-macr also helps to define lists of dependencies and include in spec file.
#8 Updated by okurz about 1 year ago
Discussed with tinita and mkittler and we re-confirmed what I wrote in #53546#note-1 , there is one noteworthy difference. The openqa_dev container definition is now only used within os-autoinst but stored in the openQA repo. That one can be moved to os-autoinst instead.
Yes, I think https://build.opensuse.org/package/show/devel:openQA/openqa_dev can now be deleted
Edit: actually it is still used as the documented way to run tests locally.
- Status changed from Blocked to New
- Assignee deleted (
- Priority changed from Normal to Low
- Target version changed from Ready to future
a major part of making working with dependencies has been done by tinita in #43619 . We don't have a good idea for the other points mentioned. I would still favor a solution that is less openSUSE centric and duplicates less code in our source repo even if it is auto-generated so I will keep the ticket but keep out of our backlog as an idea for later.