Clarify that plan context is not applied to plan

[psss]

Make it clear that plan cannot define context for itself.

Pull Request Checklist

• update the specification

[LecrisUT]

I.e. it only applies to test? What about plan.import if it is expanded to allow for context as well.

[psss]

I.e. it only applies to test?

Yes, that's the current definition:

Define the default context values for all tests executed under the given plan.

What about plan.import if it is expanded to allow for context as well.

Currently we allow to modify remote plan only by environment and enabled:

The imported plan can be modified in only two ways. First way
is via environment variables. Variables defined in the plan
override any variables defined in the remote plan.

The imported plan can also be altered using the enabled key.
If the local plan is enabled, it will follow the status of the
remote plan – whether it’s enabled or disabled. If the local
plan is disabled, the remote plan will also be disabled.
Adjust rules are respected during this process.

What would be the use case for the import plan and context adjustment?

[LecrisUT]

What would be the use case for the import plan and context adjustment?

Because you cannot use adjust on environment variables. The idea is to have an interface for reusable plans, similar to GH reusable workflows. An example of that would be to expose a use_container context to use a container for the tests (thinking of rpminspect in this case), where the container is selected by the value of that context. Related to this issue

[psss]

I see, that definitely makes sense. This would give some nice flexibility. But we need to clarify, what exactly would happen. Eg., based on the context of the referencing plan the referenced plan would be adjusted? Or just the context of the referencing plan would be extended? Sorry, currently have no time to dive deeper but in general the direction seems reasonable to me.

[LecrisUT]

But we need to clarify, what exactly would happen.

Here are a few points about it:

• If both consumer and imported have context defined: Consumer's wins and it updates the fields that both define. Was thinking of fmf syntax, but I think it would create too much confusion with the inheritance from the non-consumer plans
• If CLI also defines a context: CLI value wins over all of them
• Tests use the context defined by both consumer and imported as above
• All context there are treated as if they were passed from cli to the imported plan, i.e. being available for any adjust operations, overwriting plan's context, etc.

I think the last point would be a good sum-up for the user to know what to expect.

[psss]

Sounds like a good outline, let's finalize the wording in the respective pull request.