IIUIC, the only "benefit" of these changes isthe fact you can pass test_config dict to the create_app function, instead of setting TEST=true env in testing/conftest.py to load the Test config.

I might be missing something, but I don't really see the testability increase here. I might be just limited in my understanding of the benefits, by the scope of the apps we develop, but I'm not sure the (from my point of view) minor enhancements outweighs the gained complications it brings because of the current_app being available only at request, or app creation - like before/after request handling, access to app out of the request scope (I'm shooting a bit wild bere, but Alembic and cmdline interface come to mind).

IMO pruning the __init__.py, and/or making sure all the "options" are working properly, and sensible, would be of bigger benefit.

I could see the value of the factory pattern, if we wanted to serve multiple instances of the same app, but with different configs from a single web-server (but then again, I think we have bigger fish to fry with the way our apps are served in the first place).

So, what would be the actual benefits to this, compared to the way we develop/test the flask apps ATM? To me, it just seems like we would be replacing one "weird thing" in one place(setting the env variable in conftest.py), for multiple new ones scattered all over the code.

On top of that, I'm still not convinced that dropping execdb alltogether would not be the better option.

IIRC, it now serves a two-fold purpose:

1. creating the UUID
2. acting as a HUB through which an informed user can tie the 'result' in resultsdb with the 'build' in buildbot (by visiting the result's Group, and then clicking on logs link to get to the ExecDB interface, where the link to the Buildbot job is provided

UUID could easily be generated in trigger, easily (just replacing the ExecDB api call with the proper "give me an UUID" method from python's stdlib).

With the second point - I'm not sure anybody really uses it, but we could easily create a file in artifacts directory containing an url of the relevant build, and pointing the resultsdb's Group log-link to that file. Sure, this would mean a change in Taskotron (resultsdb_directive, specifically IMO), but it would be minor, and it IMO is tempting to just drop the whole ExecDB, when it's so easy to replace.

...in artifacts directory containing an url of the relevant build, and pointing the resultsdb's Group log-link to that file.

Or we could setup mod_rewrite to treat the file as a rewrite map, and the client could be redirected to the buildbot's build detail directly, replacing the current functionality in a seamless way: https://httpd.apache.org/docs/2.4/rewrite/rewritemap.html#txt (not sure it's worth the trouble, nor necessary, just wanted to show the possibility)

On top of that, I'm still not convinced that dropping execdb alltogether would not be the better option.

I just talked to @adamwill and he asked us whether we could support the new standard for CI messages in Taskotron:
https://pagure.io/fedora-ci/messages
That would mean we send a message when a task is created/scheduled, started executing, and finished executing. Currently we only support messages when the result is posted, IIRC (which also not always matches the input parameters of the scheduled task, e.g. rpmdeplint).
I'd wait with the implementation at least until we talk to Miro Vadkerti next week, but this might be a reason why ExecDB could still be useful for tracking these states (and possibly sending the messages). So this might need some additional thought before we decide to drop it or not. If there's an easy way to work with the new buildbot and still keep it, I guess that would be preferable for the moment (or wait for the next week's discussions).

Fair point, even though I still believe the ExecDB is not needed even for this, and the messages can as easily be sent from trigger and buildbot.
All in all, ExecDB, as is, IMO does not add any benefit, and only adds to the amount of stuff we need to keep running. It merelyre-stores the data already present in other places (mostly buildbot), while not adding significant amount of data on top of that.
With the changes in buildbot/execdb, it will only really store the "job was triggered, buildbot started, buildbot finished" information, since we will lose all the "steps" information (buildbot does not send push notifications on step changes any more).

If both of you are set on/prefer keeping execdb in place, I'm not the one to keep you from it. I'm merely trying to point out, that it was/is mostly irrelevant, and that I'm not sure investing any time into re-implementing it/keeping it alive makes sense.

Not much more I could add to that, I think.

We talked about this in person and decided to go with the easiest change possible so I'm closing this PR, will remove the refactoring and just change how execdb is handling incoming data