Trying to remove the hard-coded subject_types, and put the list of available subject_types inside the configuration, but the greenwave/policies.py file seems to have issues with imports/scope.
How about allowing any subject type (as discussed in #339)? This could simplify the code a bit more.
It would be nice if this conversion came from the config as well. For example:
# In config 'subject_type_overrides': {'brew-build': 'koji_build'} # In code: subject_type = current_app.config['subject_type_overrides'].get(subject_type, subject_type)
That woulnd't be bad... but we would still need to have some hard-coded stuff (like compose, original_spec_nvr), but we would have that anyway... What the team think? @lucarval
How about allowing any subject type (as discussed in #339)? This could simplify the code a bit more. That woulnd't be bad... but we would still need to have some hard-coded stuff (like compose, original_spec_nvr), but we would have that anyway... What the team think? @lucarval
I like the idea of having things more dynamic and avoid updating code and/or config to add support for new subject_types. The only downfall I can think of is that if someone makes a typo in this field it won't be immediately obvious. But this is probably ok.
Ok, I'm gonna try this option. I like it more too. Let's keep this PR a bit if you don't mind, then we can drop it in favour of the other one.
Pull-Request has been closed by gnaponie
Trying to remove the hard-coded subject_types, and put the list of
available subject_types inside the configuration, but the
greenwave/policies.py file seems to have issues with imports/scope.