Background
The prepare/artifact plugin's verify phase injection currently uses a static set of phase names to decide which tmt-managed install phases should be covered by verification (source):
_tmt_install_phase_names = {
'essential-requires',
'requires',
'recommends',
'requires (dist-git)',
'recommends (dist-git)',
}
This list is hard to maintain: every time a new source of tmt-injected install phases is added (e.g. a new dist-git variant, a new built-in prepare plugin), the artifact plugin needs a matching update.
Proposed improvement
Add a lightweight subscription/registration mechanism so that plugins which inject install phases on behalf of tmt can declare themselves as candidates for artifact verification, instead of the artifact plugin hard-coding their names.
A simple approach could be a class-level marker or a registry call on PrepareInstall subclasses/instances — similar to how @provides_method already works for plugin discovery.
The mechanism should remain simple. The goal is not to build a general-purpose event system, but to remove the need for the static name list while keeping the intent clear.
Notes
- Not a blocker — the current static list works for all known cases today.
- Ideally the solution would also cover any future case where all tmt-injected install phases end up being verified, making the opt-in the default rather than the exception.
Background
The
prepare/artifactplugin's verify phase injection currently uses a static set of phase names to decide which tmt-managed install phases should be covered by verification (source):This list is hard to maintain: every time a new source of tmt-injected install phases is added (e.g. a new dist-git variant, a new built-in prepare plugin), the artifact plugin needs a matching update.
Proposed improvement
Add a lightweight subscription/registration mechanism so that plugins which inject install phases on behalf of tmt can declare themselves as candidates for artifact verification, instead of the artifact plugin hard-coding their names.
A simple approach could be a class-level marker or a registry call on
PrepareInstallsubclasses/instances — similar to how@provides_methodalready works for plugin discovery.The mechanism should remain simple. The goal is not to build a general-purpose event system, but to remove the need for the static name list while keeping the intent clear.
Notes