Consider moving all demo flow blueprints into a demo folder

[anna-geller]

So far, we were using the demo: true property in the extend metadata to highlight which blueprints can be used for QA https://github.com/kestra-io/blueprints/blob/main/flows/api-python-sql.yaml#L63

This was working great in Strapi but now it's cumbersome for QA

[anna-geller]

Ben assigned you just to make it clear you're in charge here to coordinate 👍

[Ben8t]

using the demo: true property in the extend metadata to highlight which blueprints can be used for QA

@anna-geller I'm not sure it was the primary usage. After looking at some of them, many has secret or taskRunner: process that make it hard to use for QA (either lack of creds. or because of limited taskRunner to Docker)

I was about to move some of the demo: true to demo:false but I think it was related to the actual demo we provided directly from the website.

-> Are we ok to remove some demo:true (even if it's a good blueprint for "demo" of Kestra - just not working per se, in a self-contained way)?

By the way, I've worked on a CI that take blueprints, parse the extend props. and only use the one with demo:true (cf here) as sanitycheck (and remove the extend property so we could resolve kestra-io/kestra#6385)

[anna-geller]

yes for sure, if some demo: true are not working as expected (self-contained), we should either fix them or set demo: false

[Ben8t]

Closing this one as I removed the demo: true for blueprints which are not self contained here.