plugin: Cannot define parmeterless plugins about tmt HOT 8 OPEN

Coincidentally I hit the same problem and it is caused by https://github.com/teemtee/tmt/blame/43ac6e339dc4ee8e41a1c8fdcf8f7b91e1e7d0a8/tmt/steps/prepare/__init__.py#L147

Currently trying to remember why such line was added.

Workaround for now can be to define own in plugins dataclass

@dataclasses.dataclass
class PrepareXData(tmt.steps.prepare.PrepareStepData):
    @property
    def is_bare(self):
        return False

from tmt.

That’s weird. We can see how: tmt in many, many plans, with no extra options, so I’d say the problem will be something else than “cannot define”. Is there an error message? How does debug log looks like, with —log-topic=cli-invocations there should be a very detailed description of phase processing. Can you share the plugin code? Might be related to step_data, but even the default should be good enough.

from tmt.

It is in the current iteration of LecrisUT/tmt-cmake#5 (but also on the main branch there). No, no errors are introduced, but also nothing is executed. wake/show are entered, but the actual execution or display does not occur. I'll probably run with debug later

from tmt.

Here's a log example running:

prepare:
  how: cmake
#  build_dir: build
execute:
  script: /bin/true

(test/integration/prepare in the plugin repo)

$ tmt run -ra --log-topic=cli-invocations provision --how local
/var/tmp/tmt/run-067
    warn: /plan:prepare - {'how': 'cmake'} is not valid under any of the given schemas

/plan
    discover
        how: shell
        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 40 (KDE Plasma Prerelease)
    
        summary: 1 guest provisioned
    prepare
        queued push task #1: push to default-0
        
        push task #1: push to default-0
    
        queued prepare task #1: requires on default-0
        
        prepare task #1: requires on default-0
        how: install
        summary: Install required packages
        name: requires
        where: default-0
        package: /usr/bin/flock
    
        queued pull task #1: pull from default-0
        
        pull task #1: pull from default-0
    
        summary: 1 preparation applied
    execute
        queued execute task #1: default-0 on default-0
        
        execute task #1: default-0 on default-0
        how: tmt
        progress:                 
    
        summary: 1 test executed
    report
        how: display
        summary: 1 test passed
    finish
    
        summary: 0 tasks completed

total: 1 test passed

from tmt.

I think the only reasonable usage is in

But over there also I think it should be after the how: is printed, at least if it's not the default how

from tmt.

I believe the check for empty data is included in order to drop the default empty phase which is created here:

And that one is created so that there's something which can be overridden from the command line, for example:

tmt run -vvv -a prepare -h install -p tree

When run with the following plan:

provision:
    how: container
execute:
    script: tree

It would be better to create a new phase object only if the respective command line option is provided.

from tmt.

You mean that there is effectively a pre-existing:

prepare:
    how: install
    packages: [ ]

In the CLI, doesn't the prepare -h install -p tree effectively add a prepare step anyway? I think it would be better to have such a behavior as opt-in, something like having a property can_skip which can be linked to if self.data.packages. is_bare seems to be more along the line for checking if something was passed to it or not.

from tmt.

It's more like a how: something tentative, not really an install incarnation. It's an empty phase into which the default how, i.e. shell, would be injected. The magic is, if it's shell but without any scripts, there's no point to run it, is it? I'll try to poke it, I already wandered around CLI invocations.

from tmt.