I <3 this idea.

Sounds like a good idea. How about following format?

Greenwave policies:

--- !Policy
id: "taskotron_release_critical_tasks_for_stable"
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
  - !RemoteRule {}
  - !PassingTestCaseRule {test_case_name: always.required.test.case}

--- !Policy
id: "base_policy_1"
product_versions:
  - fedora-*
decision_context: base_policies
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: default.test.case.1}

--- !Policy
id: "base_policy_2"
product_versions:
  - fedora-31
decision_context: base_policies
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: default.test.case.2}

gating.yaml:

--- !Policy
inherits:
  - base_policies
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
rules:
  - !PassingTestCaseRule {test_case_name: additional.test.case}

So a build with this file requires:
- always.required.test.case
- default.test.case.1
- default.test.case.2 (only when build's product version is f31)
- additional.test.case

Listing decision contexts in inherits that are not defined in Greenwave could be treated as an error.

The inherits field could also be used to remove duplicate code from Greenwave policies (same lists of product versions, rules etc.).

Could we make the gating.yaml even simpler?

I'm fine with having it more complex when people want to add specific rules, but if we could make it dead simple for the default rules it would be very nice I think :)

Could we make the gating.yaml even simpler?

I think gating.yaml could contain just the following to enable the opt-in policies.

--- !Policy
inherits: [base_policies]

What if then packagers want to add an additional policy that it is not in the list? How should they do that?
And additionally: how would they know what's the name of what they have to inherit?

What if then packagers want to add an additional policy that it is not in the list? How should they do that?

I'd say they go back to the current format :)

And additionally: how would they know what's the name of what they have to inherit?

Documentation :)

What if then packagers want to add an additional policy that it is not in the list? How should they do that?

I'd say they go back to the current format :)

So you would like to have both formats available?

And additionally: how would they know what's the name of what they have to inherit?

Documentation :)

Which documentation? Greenwave's docs is for the software, not for the configuration of a specific instance.

So you would like to have both formats available?

I don't think we can move away from the current format since that would anyway
break backward compatibility.

What I have in mind is more something like:

if file_content == 'default_policy':
   get_default_policy_from_main_config
else:
   load_policy_as_usual

Does that make sense?

And additionally: how would they know what's the name of what they have to inherit?

Documentation :)

Which documentation? Greenwave docs is for the software, not for the configuration of a specific instance.

The doc about CI in Fedora, clearly not something that is related to the
upstream greenwave doc :)

Does that make sense?

It does. But can you post an example of a gating.yaml file format that you have in mind?
It would be either the "usual" one or something similar to what @lholecek posted?

The doc about CI in Fedora, clearly not something that is related to the
upstream greenwave doc :)

Sounds good to me.

It does. But can you post an example of a gating.yaml file format that you have in mind?
It would be either the "usual" one or something similar to what @lholecek posted?

Oh, I really don't have a clear idea of what it could look like.
The proposal from:
https://pagure.io/greenwave/issue/466#comment-584674
looks quite good. (is the --- o!Policy needed? I should check the yaml spec
one day...)

It may be an idea to follow up with this on the devel list to see what people
think about it?

looks quite good. (is the --- o!Policy needed? I should check the yaml spec
one day...)

I was thinking about removing it. I don't quite remember what's the reason behind it. Maybe we can make sure it's not important and eventually remove it.

It may be an idea to follow up with this on the devel list to see what people
think about it?

That's fine by me. Could you do it?

cc. @lucarval wdyt?

A couple of points:

1. I don't think Policy inheritance is needed. Just a mechanism to say "I want to use this policy that is defined somewhere else" is sufficient. If additional policies are wanted, you could also define them directly in gating.yaml. Right?
2. How does gating.yaml reference a policy that is defined in Greenwave? It looks like the suggestion above was to use decision_context but that seems odd to me. Why not use the policy id?
3. Do we need to have a mechanism to define a policy in Greenwave, but have it be used in multiple decision contexts? I mention it here because you may want to "override" the decision_context, for example. (Perhaps inheritance is a good idea after all :smile: )

Do we have any practical gating.yaml file and Greenwave policy file to describe the pain point for this improvement? From the implementation, it is more like the Greenwave' policy file will include package specific remote rules, the package remote policy file is more like an extension instead of an inheritance. So I am wondering if anyone can help to give some practical cases so that I can fully understand the issue. Thanks in advance!