QA (public) » openQA Project (public)

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.

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.

@mkittler @tinita see #53546#note-8 , we still have both "openqa_dev" and "os-autoinst_dev" in https://build.opensuse.org/project/show/devel:openQA , can we delete the first or something?

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.

PR to remove Dockerfile in openQA: https://github.com/os-autoinst/openQA/pull/3372