Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exec-test: allow setting of the working directory #5937

Open
clebergnu opened this issue May 21, 2024 · 2 comments
Open

exec-test: allow setting of the working directory #5937

clebergnu opened this issue May 21, 2024 · 2 comments
Labels
customer:Passt Requirements/issues raised by the Passt project enhancement

Comments

@clebergnu
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The exec-test test type allows users to run an executable given by absolute path, or more commonly by relative path. In both cases, the current working directory inherited by Avocado or the specific test runner (say avocado-runner-exec-test) may not be appropriate to the executable.

One common situation is when using an executable that will depend on files located somewhere else in the filesystem. For instance, having a runnable's uri of make, together with a make target as an argument given to args, will depend on the location of the Makefile containing that target.

The goal here is to implement a way to control how exec-tests can set their current working directory, so that use cases such as make <target> can be defined with uri and args in a way that makes the execution relocatable (that is, does not depend on running from a specific location).

Describe the solution you'd like
A configuration option such as runner.exectest.cwd can take a number of options that will control the current working for the executables themselves. For instance:

  • DIR_OF_URI: would set the executable current working directory to the directory name of the URI
  • $ARGS[0]: would set the current working directory to the same directory given as the first argument
  • $KWARGS["WORKING_DIR"]: would set the executable current working directory to the location of the WORKING_DIR keyword argument.

Describe alternatives you've considered
None.

Additional information
None

@clebergnu clebergnu added enhancement customer:Passt Requirements/issues raised by the Passt project labels May 21, 2024
@clebergnu clebergnu added this to the #106 - Codename TBD milestone May 21, 2024
@mr-avocado mr-avocado bot moved this to Triage in Default project May 21, 2024
@clebergnu
Copy link
Contributor Author

Hi @dgibson, can you share your opinion on this? Thanks!

@dgibson
Copy link
Contributor

dgibson commented Sep 12, 2024

Hi @clebergnu, sorry it's taken me a while to look at this.

I don't think setting the cwd relative to the uri or one of the arguments is very useful.

  • If the uri/arg is an absolute path then you must know that absolute path when writing the .json (by hand or by script) in which case you could equally well set the desired cwd as an absolute path
  • If the uri/arg is a relative path, then when writing the .json you still need to know what cwd Avocado will be invoked from in order to correctly generate the uri/arg.
  • In fact using a relative path for arg specifically is basically impossible: if Avocado changes cwd based on it, then the relative path will no longer be correct when the program at the uri goes to interpret the argument.

Instead, what I think would be useful is to be able to set the cwd as a path relative to the directory if the .json itself. That way a .json can refer to things within (say) its own repository in a way that won't break if the whole repository is moved around. For simplicity/brevity, I'd prefer uri was also interpreted relative to the configured cwd - that's more or less necessarily true of any arguments.

For example, in some source tree test/tests.json might have:

[
    {
        "kind": "exec-test",
        "identifier": "build",
        "cwd": "..",
        "uri": "make",
        "args": ["all"]
    },
    {
        "kind": "exec-test",
        "identifier": "lint",
        "cwd": "..",
        "uri": "scripts/lintscript",
        "args": ["-C", "test/lintconfig"]
    }
]

I don't personally see a use for setting cwd based on kwargs, but it might be useful to someone, so I have no strong opinion on that option.

What might be useful, would be the ability to pass the test an environment variable (or Python kwarg, I guess) that's given as a path relative to the .json's location. Once inside the test the variable would have the absolute path, or a path relative to the actual cwd. This is technically unrelated to setting of the cwd, but overlaps in use case, since it could pass information that the test itself could use to control its cwd. e.g.

[
    {
        "kind": "exec-test",
        "identifier": "complicated-test",
        "uri": "./complicated_test",
        "env": { "REPOBASE": "{jsonpath}/.." }
    }
]

(the specific syntax I'm using there is just an example to get the idea across, I don't think it would be a good choice for a final syntax).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer:Passt Requirements/issues raised by the Passt project enhancement
Projects
Status: Short Term (Current Q) Backlog
Development

No branches or pull requests

3 participants