Add development service convenience runner "openqa-run"

[okurz]

No description provided.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching docs/*.asciidoc:

• Consider generating documentation locally to verify it is rendered correctly using tools/generate-docs

This is an automatically generated QA checklist based on modified files.

[b10n1k]

thanks first of all, but just no. IMO this is incomplete and make it even more confusing. Sorry.

[Martchus]

All in all I'd say: no
This is causing more confusion than it is helping.

[Martchus]

I really don't like the idea of calling the Mojo app as geekotest.

This script intends to use a sub directory of the Git checkout as OPENQA_BASEDIR to it should invoke everything as the user this checkout was made by. That's probably just the current user and not geekotest:

Suggested change

	sudo -u geekotest OPENQA_BASEDIR="${OPENQA_BASEDIR}" "$@"
	"$@"

Note that if one just checks out the Git repo (for development, without having any packages installed) the user geekotest might not even exist.

[kalikiana]

Why is geekotest even used here? I always considered that a detail of the production setup on e.g. o3 and not something I generally have for development

[okurz]

I really don't like the idea of calling the Mojo app as geekotest.

This script intends to use a sub directory of the Git checkout as OPENQA_BASEDIR to it should invoke everything as the user this checkout was made by. That's probably just the current user and not geekotest:

Note that if one just checks out the Git repo (for development, without having any packages installed) the user geekotest might not even exist.

Yes, correct. But we need to provide a database with the according role. So should we also set the database connection to use an automatically started test database from t/test_postgresql?

Why is geekotest even used here? I always considered that a detail of the production setup on e.g. o3 and not something I generally have for development

no, geekotest is also the user used within the packaged version and hence also the user that would be used in the initial database setup which one might want to reuse when running from the development directory.

[Martchus]

I would not recommend to reuse the same database.

[okurz]

So do you recommend to use an automatically started test database from t/test_postgresql?

[Martchus]

Not sure whether that's the best idea. I get the idea of reusing test fixtures. However, it is also a bit problematic as this might lead to accidental cluttering and changes in that directory. This might be annoying because those changes might show up in Git (and we cannot just ignore them because files in that directory are supposed to be under version control) and might also lead to failures when running unit tests (which might not be obvious to debug).

[okurz]

We could create a temporary directory and use that.

[Martchus]

This kind of usage is very annoying without auto completion. In my helper is worked around this via shortcuts.

The script doesn't seem to ensure that e.g. openqa-webui-daemon is actually in the PATH so I guess this example also won't lead to a great out-of-the-box experience even if copied verbatimly. (The example you added to the docs does make sense, though.)

[Martchus]

I disagree. The service account this script chooses is not appropriate for local development. I recommend not to mix the production/packaged setup with the development environment.

This description also makes it not clear at all to what OPENQA_BASEDIR is actually set (because "your local development environment" is not clear in this context, apparently it means test files from the current working dir but also only if OPENQA_BASEDIR is not set anyway).